[Users] vdsm live migration errors in latest master

[Federico Simoncelli]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Federico Simoncelli" <fsimonce at redhat.com>
> Cc: "Dead Horse" <deadhorseconsulting at gmail.com>, "users" <users at ovirt.org>, vdsm-devel at fedorahosted.org,
> abaron at redhat.com
> Sent: Thursday, September 26, 2013 1:38:15 AM
> Subject: Re: [Users] vdsm live migration errors in latest master
> 
> On Tue, Sep 24, 2013 at 12:04:14PM -0400, Federico Simoncelli wrote:
> > ----- 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
> 
> Beyond this, we must make sure that on Engine side, the extended shared
> values would be used only for clusterLevel 3.4 and above.
> 
> Are the extended shared values already used by Engine?

Yes. That's the idea. Actually to be fair, the second case you mentioned
(migrating from extended shared property to old vdsm) it wouldn't have been
possible I suppose (the issue here is that Dead Horse has one or more
hosts running on master instead of 3.3). The extended shared property would
have appeared only in 3.4 and to allow the migration you would have had to
upgrade all the nodes.

But anyway since we were also talking about a new 3.3.1 barnch I just went
ahead and covered all cases.

-- 
Federico