As you can see in a previous patch set I checked if the alias attribute exists instead of
assuming it exists.
I then changed my mind with Dan's blessing, and decided to assume it does exist,
exactly for cases like this.
Even if we check if the alias exists, what do we do if we find out it doesn't?
We're at a problem and need to understand why the alias doesn't exist because it
should - For all devices.
We definitely need to deal with this issue - Can you provide the domxml of the VM during
creation, and during migration?
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com>
To: "Vinzenz Feenstra" <vfeenstr(a)redhat.com>, "Assaf Muller"
<amuller(a)redhat.com>
Cc: "vdsm-devel(a)lists.fedorahosted.org Development"
<vdsm-devel(a)lists.fedorahosted.org>, "Dan Kenigsberg"
<danken(a)redhat.com>
Sent: Wednesday, May 22, 2013 3:56:22 PM
Subject: Re: [vdsm] Migration regression on master
On May 22, 2013, at 10:14 , Vinzenz Feenstra <vfeenstr(a)redhat.com> wrote:
Hi,
During the verification of the refactoring in VDSM (libvirtvm + vm == vm) we have
encountered some issue.
There seems to be a regression on master branch regarding device aliases.
On the target machine _updateDevicesDomxmlCache accesses dev.alias without the attribute
being present.
This happens to happen at least on balloon devices.
I am not sure why we do have this, however it is reproducible and I am not sure why we do
this now.
I know it has been introduced by
http://gerrit.ovirt.org/#/c/13876 and it's actually
in the commit message that we'd fail.
:-) you mean:
* We now crash horribly if an alias was not found for a device
when updating devices domxml cache after migrating
Which is the case... So can somebody please enlighten me and tell me
if this is a configuration issue of the VM or if this really a regression.
not all
devices have alias so I think this is indeed a regression
It's possible that the tests aren't properly configured,
however that would from my understanding mean that we potentially will run into troubles
during migrations from 3.2 -> 3.3 vdsm.
PS:
This kind of blocks a bit the refactoring verification :/
--
Regards,
Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo
Better technology. Faster innovation. Powered by community collaboration.
See how it works at
redhat.com
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel