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. 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.
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 :/
On May 22, 2013, at 10:14 , Vinzenz Feenstra vfeenstr@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
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@redhat.com To: "Vinzenz Feenstra" vfeenstr@redhat.com, "Assaf Muller" amuller@redhat.com Cc: "vdsm-devel@lists.fedorahosted.org Development" vdsm-devel@lists.fedorahosted.org, "Dan Kenigsberg" danken@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@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
vdsm-devel@lists.fedorahosted.org