----- Original Message ----- > From: "Dan Kenigsberg" <dan...@redhat.com> > To: "Dead Horse" <deadhorseconsult...@gmail.com> > Cc: "<users@ovirt.org>" <users@ovirt.org>, vdsm-de...@fedorahosted.org, > fsimo...@redhat.com, aba...@redhat.com > Sent: Tuesday, September 24, 2013 11:44:48 AM > Subject: Re: [Users] vdsm live migration errors in latest master > > On Mon, Sep 23, 2013 at 04:05:34PM -0500, Dead Horse wrote: > > Seeing failed live migrations and these errors in the vdsm logs with latest > > VDSM/Engine master. > > Hosts are EL6.4 > > Thanks for posting this report. > > The log is from the source of migration, right? > Could you trace the history of the hosts of this VM? Could it be that it > was started on an older version of vdsm (say ovirt-3.3.0) and then (due > to migration or vdsm upgrade) got into a host with a much newer vdsm? > > Would you share the vmCreate (or vmMigrationCreate) line for this Vm in > your log? I smells like an unintended regression of > http://gerrit.ovirt.org/17714 > vm: extend shared property to support locking > > solving it may not be trivial, as we should not call > _normalizeDriveSharedAttribute() automatically on migration destination, > as it may well still be apart of a 3.3 clusterLevel. > > Also, migration from vdsm with extended shared property, to an ovirt 3.3 > vdsm is going to explode (in a different way), since the destination > does not expect the extended values. > > Federico, do we have a choice but to revert that patch, and use > something like "shared3" property instead?
I filed a bug at: https://bugzilla.redhat.com/show_bug.cgi?id=1011608 A possible fix could be: http://gerrit.ovirt.org/#/c/19509 -- Federico _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users