----- Original Message -----
> From: "Dan Kenigsberg" <dan...@redhat.com>
> To: "Dead Horse" <deadhorseconsult...@gmail.com>
> Cc: "<us...@ovirt.org>" <us...@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
> 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:
A possible fix could be:
vdsm-devel mailing list