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.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
---
tests/qemu-iotests/iotests.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index f5ca4b8..e110c90 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -168,6 +168,8 @@ class VM(qtest.QEMUQtestMachine):
options.append('file=%s' % path)
options.append('format=%s' % format)
options.append('cache=%s' % cachemode)
+ if 'node-name' not in opts:
+ options.append('node-name=drivenode%d' % self._num_drives)
if opts:
options.append(opts)
--
1.8.3.1
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?
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> Reviewed-by: Max Reitz <mreitz@redhat.com>
> ---
> tests/qemu-iotests/iotests.py | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index f5ca4b8..e110c90 100644
> --- a/tests/qemu-iotests/iotests.py
> +++ b/tests/qemu-iotests/iotests.py
> @@ -168,6 +168,8 @@ class VM(qtest.QEMUQtestMachine):
> options.append('file=%s' % path)
> options.append('format=%s' % format)
> options.append('cache=%s' % cachemode)
> + if 'node-name' not in opts:
> + options.append('node-name=drivenode%d' % self._num_drives)
>
> if opts:
> options.append(opts)
> --
> 1.8.3.1
>
>
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?
>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>> Reviewed-by: Max Reitz <mreitz@redhat.com>
>> ---
>> tests/qemu-iotests/iotests.py | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
>> index f5ca4b8..e110c90 100644
>> --- a/tests/qemu-iotests/iotests.py
>> +++ b/tests/qemu-iotests/iotests.py
>> @@ -168,6 +168,8 @@ class VM(qtest.QEMUQtestMachine):
>> options.append('file=%s' % path)
>> options.append('format=%s' % format)
>> options.append('cache=%s' % cachemode)
>> + if 'node-name' not in opts:
>> + options.append('node-name=drivenode%d' % self._num_drives)
>>
>> if opts:
>> options.append(opts)
>> --
>> 1.8.3.1
>>
>>
--
Best regards,
Vladimir
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? Fam
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? Why not configurable? libvirt can use same parameters as I in this patch.. Or what do you mean? > > Fam -- Best regards, Vladimir
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. Fam
* Fam Zheng (famz@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 / dgilbert@redhat.com / Manchester, UK
On 02/17/2017 02:51 PM, Dr. David Alan Gilbert wrote: > * Fam Zheng (famz@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 / dgilbert@redhat.com / Manchester, UK > Sorry for the necromancy, looks like discussion died here. Vladimir, what's plans? --js
11.04.2017 00:49, John Snow wrote: > > On 02/17/2017 02:51 PM, Dr. David Alan Gilbert wrote: >> * Fam Zheng (famz@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 / dgilbert@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 -- Best regards, Vladimir
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 (famz@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 / dgilbert@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. -- Best regards, Vladimir
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 (famz@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 / dgilbert@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
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. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
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.
© 2016 - 2026 Red Hat, Inc.