Re: [Users] Help - Cannot run VM. Invalid time zone for given OS type.
On Jan 6, 2014, at 17:41 , Itamar Heim ih...@redhat.com wrote: On 01/06/2014 12:29 AM, Roy Golan wrote: On Mon 06 Jan 2014 12:24:53 AM IST, Roy Golan wrote: On Fri 03 Jan 2014 04:20:19 PM IST, Michal Skrivanek wrote: On 3 Jan 2014, at 15:04, Itamar Heim wrote: On 01/03/2014 12:22 PM, Sven Kieske wrote: Hi, I'm a little surprised by this development technique. its not a development technique. its a bug in upgrade or export/import of the change to the much more powerful config file based OsInfo implementation in 3.3. though i thought we already fixed it. ok, finally got to it…. it has been fixed by [1] in 3.3.1, it was released in November, an upgrade should be your solution. too bad the fix didn't make the 3.3.0...just by couple of days:/ Thanks, michal michal/roy - isn't this fixed already? It is fixed for a long time. I think it's a TZ problem, not really osinfo. I may not recall this correctly but I think the problematic code wasn't even released, it was broken just for couple of weeks, that's why I'm curious what is the exact release where it was exported to confirm it's not related to osinfo unification of Other. In my world, when you change data formats in a not compatible way you should also write some sort of transition code to convert the old data to the new data format for all possible cases. And if this is not possible for some reason, at least document this prominent in the release notes. In which version did this change occur? With such bad behaviour, I doubt we will ever get to something like a stable release. I'm sorry when I missed the part of the release notes where this is described and I'm happy if I'm totally wrong and just didn't look good enough to find it. Please point me to some docs which mention this behaviour. Am 03.01.2014 10:54, schrieb Patrick Hurrelmann: Hi Dan, I had the very problem myself. The fix for it is quite easy, but requires manual editing of one database table. In table vm_static find your non-starting vms (they propably all have an empty string set as timezone in column time_zone) and update that column to null. There was a recent change in the timezone code and it now fails when the timezone is an empty string, but works fine if it null. Regards Patrick Not an osinfo issue, this is a bug in input validation. and here is the fix [1] [1] http://gerrit.ovirt.org/22989 please make sure to backport to 3.3 stable branch so it will make ovirt 3.3.3. thanks, Itamar [1] http://gerrit.ovirt.org/#/c/20292/ ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Help - Cannot run VM. Invalid time zone for given OS type.
On 01/06/2014 12:29 AM, Roy Golan wrote: On Mon 06 Jan 2014 12:24:53 AM IST, Roy Golan wrote: On Fri 03 Jan 2014 04:20:19 PM IST, Michal Skrivanek wrote: On 3 Jan 2014, at 15:04, Itamar Heim wrote: On 01/03/2014 12:22 PM, Sven Kieske wrote: Hi, I'm a little surprised by this development technique. its not a development technique. its a bug in upgrade or export/import of the change to the much more powerful config file based OsInfo implementation in 3.3. though i thought we already fixed it. michal/roy - isn't this fixed already? It is fixed for a long time. I think it's a TZ problem, not really osinfo. I may not recall this correctly but I think the problematic code wasn't even released, it was broken just for couple of weeks, that's why I'm curious what is the exact release where it was exported to confirm it's not related to osinfo unification of Other. In my world, when you change data formats in a not compatible way you should also write some sort of transition code to convert the old data to the new data format for all possible cases. And if this is not possible for some reason, at least document this prominent in the release notes. In which version did this change occur? With such bad behaviour, I doubt we will ever get to something like a stable release. I'm sorry when I missed the part of the release notes where this is described and I'm happy if I'm totally wrong and just didn't look good enough to find it. Please point me to some docs which mention this behaviour. Am 03.01.2014 10:54, schrieb Patrick Hurrelmann: Hi Dan, I had the very problem myself. The fix for it is quite easy, but requires manual editing of one database table. In table vm_static find your non-starting vms (they propably all have an empty string set as timezone in column time_zone) and update that column to null. There was a recent change in the timezone code and it now fails when the timezone is an empty string, but works fine if it null. Regards Patrick Not an osinfo issue, this is a bug in input validation. and here is the fix [1] [1] http://gerrit.ovirt.org/22989 please make sure to backport to 3.3 stable branch so it will make ovirt 3.3.3. thanks, Itamar ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users also as a quick workaround: psql engine postgres -c update vm_static set time_zone = NULL where time_zone = ''; ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Help - Cannot run VM. Invalid time zone for given OS type.
On Fri 03 Jan 2014 04:20:19 PM IST, Michal Skrivanek wrote: On 3 Jan 2014, at 15:04, Itamar Heim wrote: On 01/03/2014 12:22 PM, Sven Kieske wrote: Hi, I'm a little surprised by this development technique. its not a development technique. its a bug in upgrade or export/import of the change to the much more powerful config file based OsInfo implementation in 3.3. though i thought we already fixed it. michal/roy - isn't this fixed already? It is fixed for a long time. I think it's a TZ problem, not really osinfo. I may not recall this correctly but I think the problematic code wasn't even released, it was broken just for couple of weeks, that's why I'm curious what is the exact release where it was exported to confirm it's not related to osinfo unification of Other. In my world, when you change data formats in a not compatible way you should also write some sort of transition code to convert the old data to the new data format for all possible cases. And if this is not possible for some reason, at least document this prominent in the release notes. In which version did this change occur? With such bad behaviour, I doubt we will ever get to something like a stable release. I'm sorry when I missed the part of the release notes where this is described and I'm happy if I'm totally wrong and just didn't look good enough to find it. Please point me to some docs which mention this behaviour. Am 03.01.2014 10:54, schrieb Patrick Hurrelmann: Hi Dan, I had the very problem myself. The fix for it is quite easy, but requires manual editing of one database table. In table vm_static find your non-starting vms (they propably all have an empty string set as timezone in column time_zone) and update that column to null. There was a recent change in the timezone code and it now fails when the timezone is an empty string, but works fine if it null. Regards Patrick Not an osinfo issue, this is a bug in input validation. and here is the fix [1] [1] http://gerrit.ovirt.org/22989 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Help - Cannot run VM. Invalid time zone for given OS type.
On Mon 06 Jan 2014 12:24:53 AM IST, Roy Golan wrote: On Fri 03 Jan 2014 04:20:19 PM IST, Michal Skrivanek wrote: On 3 Jan 2014, at 15:04, Itamar Heim wrote: On 01/03/2014 12:22 PM, Sven Kieske wrote: Hi, I'm a little surprised by this development technique. its not a development technique. its a bug in upgrade or export/import of the change to the much more powerful config file based OsInfo implementation in 3.3. though i thought we already fixed it. michal/roy - isn't this fixed already? It is fixed for a long time. I think it's a TZ problem, not really osinfo. I may not recall this correctly but I think the problematic code wasn't even released, it was broken just for couple of weeks, that's why I'm curious what is the exact release where it was exported to confirm it's not related to osinfo unification of Other. In my world, when you change data formats in a not compatible way you should also write some sort of transition code to convert the old data to the new data format for all possible cases. And if this is not possible for some reason, at least document this prominent in the release notes. In which version did this change occur? With such bad behaviour, I doubt we will ever get to something like a stable release. I'm sorry when I missed the part of the release notes where this is described and I'm happy if I'm totally wrong and just didn't look good enough to find it. Please point me to some docs which mention this behaviour. Am 03.01.2014 10:54, schrieb Patrick Hurrelmann: Hi Dan, I had the very problem myself. The fix for it is quite easy, but requires manual editing of one database table. In table vm_static find your non-starting vms (they propably all have an empty string set as timezone in column time_zone) and update that column to null. There was a recent change in the timezone code and it now fails when the timezone is an empty string, but works fine if it null. Regards Patrick Not an osinfo issue, this is a bug in input validation. and here is the fix [1] [1] http://gerrit.ovirt.org/22989 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users also as a quick workaround: psql engine postgres -c update vm_static set time_zone = NULL where time_zone = ''; ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Help - Cannot run VM. Invalid time zone for given OS type.
On 2 Jan 2014, at 20:12, Dan Ferris wrote: Hi, Has anyone run across this error: Cannot run VM. Invalid time zone for given OS type. The OS type for these VMs is set to Linux Other. What was the original TZ in 3.2? They were all exported from an Ovirt 3.2 cluster and are being reimported into an Ovirt 3.3 cluster. Linux Other was supposed to be changed to Other on import. Did it happen correctly? None of these VMs will boot. We also can't delete them because delete protection is enabled and we can't edit the VM to turn off delete protection. Can you edit and just change the TZ to something else? Thanks, michal Does anyone know what this error means exactly and how to fix it? Thanks, Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Help - Cannot run VM. Invalid time zone for given OS type.
On 02.01.2014 20:12, Dan Ferris wrote: Hi, Has anyone run across this error: Cannot run VM. Invalid time zone for given OS type. The OS type for these VMs is set to Linux Other. They were all exported from an Ovirt 3.2 cluster and are being reimported into an Ovirt 3.3 cluster. None of these VMs will boot. We also can't delete them because delete protection is enabled and we can't edit the VM to turn off delete protection. Does anyone know what this error means exactly and how to fix it? Thanks, Dan Hi Dan, I had the very problem myself. The fix for it is quite easy, but requires manual editing of one database table. In table vm_static find your non-starting vms (they propably all have an empty string set as timezone in column time_zone) and update that column to null. There was a recent change in the timezone code and it now fails when the timezone is an empty string, but works fine if it null. Regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Help - Cannot run VM. Invalid time zone for given OS type.
Hi, I'm a little surprised by this development technique. In my world, when you change data formats in a not compatible way you should also write some sort of transition code to convert the old data to the new data format for all possible cases. And if this is not possible for some reason, at least document this prominent in the release notes. In which version did this change occur? With such bad behaviour, I doubt we will ever get to something like a stable release. I'm sorry when I missed the part of the release notes where this is described and I'm happy if I'm totally wrong and just didn't look good enough to find it. Please point me to some docs which mention this behaviour. Am 03.01.2014 10:54, schrieb Patrick Hurrelmann: Hi Dan, I had the very problem myself. The fix for it is quite easy, but requires manual editing of one database table. In table vm_static find your non-starting vms (they propably all have an empty string set as timezone in column time_zone) and update that column to null. There was a recent change in the timezone code and it now fails when the timezone is an empty string, but works fine if it null. Regards Patrick -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Help - Cannot run VM. Invalid time zone for given OS type.
On 01/03/2014 12:22 PM, Sven Kieske wrote: Hi, I'm a little surprised by this development technique. its not a development technique. its a bug in upgrade or export/import of the change to the much more powerful config file based OsInfo implementation in 3.3. though i thought we already fixed it. michal/roy - isn't this fixed already? In my world, when you change data formats in a not compatible way you should also write some sort of transition code to convert the old data to the new data format for all possible cases. And if this is not possible for some reason, at least document this prominent in the release notes. In which version did this change occur? With such bad behaviour, I doubt we will ever get to something like a stable release. I'm sorry when I missed the part of the release notes where this is described and I'm happy if I'm totally wrong and just didn't look good enough to find it. Please point me to some docs which mention this behaviour. Am 03.01.2014 10:54, schrieb Patrick Hurrelmann: Hi Dan, I had the very problem myself. The fix for it is quite easy, but requires manual editing of one database table. In table vm_static find your non-starting vms (they propably all have an empty string set as timezone in column time_zone) and update that column to null. There was a recent change in the timezone code and it now fails when the timezone is an empty string, but works fine if it null. Regards Patrick ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Help - Cannot run VM. Invalid time zone for given OS type.
On 3 Jan 2014, at 15:04, Itamar Heim wrote: On 01/03/2014 12:22 PM, Sven Kieske wrote: Hi, I'm a little surprised by this development technique. its not a development technique. its a bug in upgrade or export/import of the change to the much more powerful config file based OsInfo implementation in 3.3. though i thought we already fixed it. michal/roy - isn't this fixed already? It is fixed for a long time. I think it's a TZ problem, not really osinfo. I may not recall this correctly but I think the problematic code wasn't even released, it was broken just for couple of weeks, that's why I'm curious what is the exact release where it was exported to confirm it's not related to osinfo unification of Other. In my world, when you change data formats in a not compatible way you should also write some sort of transition code to convert the old data to the new data format for all possible cases. And if this is not possible for some reason, at least document this prominent in the release notes. In which version did this change occur? With such bad behaviour, I doubt we will ever get to something like a stable release. I'm sorry when I missed the part of the release notes where this is described and I'm happy if I'm totally wrong and just didn't look good enough to find it. Please point me to some docs which mention this behaviour. Am 03.01.2014 10:54, schrieb Patrick Hurrelmann: Hi Dan, I had the very problem myself. The fix for it is quite easy, but requires manual editing of one database table. In table vm_static find your non-starting vms (they propably all have an empty string set as timezone in column time_zone) and update that column to null. There was a recent change in the timezone code and it now fails when the timezone is an empty string, but works fine if it null. Regards Patrick ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
