On 04/26/2017 09:35 AM, Vladimir Sementsov-Ogievskiy wrote: > 11.04.2017 06:37, Vladimir Sementsov-Ogievskiy wrote: >> 11.04.2017 00:49, John Snow wrote: >>> >>> On 02/17/2017 02:51 PM, Dr. David Alan Gilbert wrote: >>>> * Fam Zheng (f...@redhat.com) 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. >>>> Always best to check with libvirt guys to see what makes sense for >>>> them; >>>> ccing in jdenemar. >>>> >>>> Dave >>>> >>>>> Fam >>>> -- >>>> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK >>>> >>> Sorry for the necromancy, looks like discussion died here. Vladimir, >>> what's plans? >>> >>> --js >> >> Looks like libvirt guys are not interested ;) >> >> I'm very busy now with other tasks, I think I'll continue work on my >> series in the list in about 1-2 weeks >> >> > > Better is push "qcow2: persistent dirty bitmaps​" series first, as after > Kevin's request about storing bitmaps in inactivate, we need some > additional mechanism here, to prevent this storing (some flag > somewhere). So, I'll wait for persistent series to be accepted and then > update these series. > >
Sounds like a plan, thank you! --js