[Users] vdsm live migration errors in latest master

Federico Simoncelli fsimonce at redhat.com
Tue Sep 24 12:04:14 EDT 2013


----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Dead Horse" <deadhorseconsulting at gmail.com>
> Cc: "<users at ovirt.org>" <users at ovirt.org>, vdsm-devel at fedorahosted.org, fsimonce at redhat.com, abaron at 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


More information about the Users mailing list