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.skriva...@redhat.com> To: "Vinzenz Feenstra" <vfeen...@redhat.com>, "Assaf Muller" <amul...@redhat.com> Cc: "vdsm-devel@lists.fedorahosted.org Development" <vdsm-devel@lists.fedorahosted.org>, "Dan Kenigsberg" <dan...@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 <vfeen...@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 mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
