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
