On 04/11/2017 09:02 AM, Eric Blake wrote: > On 02/17/2017 08:05 AM, Fam Zheng wrote: >> On Fri, 02/17 16:36, Vladimir Sementsov-Ogievskiy wrote: >>> 17.02.2017 15:21, Fam Zheng wrote: >>>> On Fri, 02/17 13:20, Vladimir Sementsov-Ogievskiy wrote: >>>>> 16.02.2017 16:48, Fam Zheng wrote: >>>>>> On Mon, 02/13 12:54, Vladimir Sementsov-Ogievskiy wrote: >>>>>>> When testing migration, auto-generated by qemu node-names differs in >>>>>>> source and destination qemu and migration fails. After this patch, >>>>>>> auto-generated by iotest nodenames will be the same. >>>>>> What should be done in libvirt to make sure the node-names are matching >>>>>> correctly at both sides? >>>>> Hmm, just set node names appropriately? >>>> But I think the problem is that node names are not configurable from >>>> libvirt >>>> today, and then the migration will fail. Should the device name take >>>> precedence >>>> in the code, to make it easier? >>> >>> libvirt can use same parameters as I in this patch.. >> >> If I'm not mistaken, libvirt can be patched to explicitly set the same node >> names in the QEMU command line, but that is some extra work to do there. My >> point is if device names are used during migration, when available, this >> patch >> and the libvirt change is not necessary. > > Ultimately, libvirt will be taught to use node names everywhere, at > which point the appearance of an autogenerated node name in a qemu > managed by libvirt will be considered a libvirt bug. We're not there > yet, but don't let auto-generated node names hold up a series. >
Yes, is there a way we can avoid this issue for now? If you have the time to issue a simple re-spin while avoiding this issue, I'd like to keep the pressure on for this series.
