Re: [Users] vdsm live migration errors in latest master

----- Original Message ----- > From: "Dan Kenigsberg" <danken(a)redhat.com&gt; > To: "Dead Horse" <deadhorseconsulting(a)gmail.com&gt; > Cc: &quot;&lt;users(a)ovirt.org&gt;&quot; <users(a)ovirt.org&gt;, vdsm-devel(a)fedorahosted.org, fsimonce(a)redhat.com, abaron(a)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