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

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?