On 3/10/20 1:21 AM, Peter Krempa wrote:
On Mon, Mar 09, 2020 at 15:11:22 -0600, Jim Fehlig wrote:
Hi all,
I noticed libvirt-tck test 207-disk-media-change.t is failing with 6.1.0,
although I _think_ the failure has actually been around since the change to
using blockdev in the qemu driver. The test essentially creates a minimal
domain with a cdrom disk device, then calls attach_device a few times,
changing the <source> of the disk. The last attach_device uses the same
<source> as when the domain was created and expects the initial and final
XML to be the same. For reference, here's a link to the test
https://libvirt.org/git/?p=libvirt-tck.git;a=blob;f=scripts/domain/207-disk-media-change.t;h=dfef7c95c9d062e0f20dd2ed53d4dfb12cca0ab3;hb=HEAD
However the test fails since the 'index' attribute of the <source> element
is not the same between initial XML (index='1') and final XML (index='5').
Indeed with each attach operation the index is incremented. Should libvirt
be fixed to always provide an index of 1 for this disk config? Or should we
adjust the test case? I'm not so familiar with this functionality but I lean
With -blockdev the 'index' will be always unique. The idea is that it
always points to the same image so if you unplug it and plug it back
even at that point it will be incremented.
This was specifically meant as a feature because during block jobs it
prevents accidentally refering to the wrong part of the backing chain.
In the above case it doesn't seem that the test is that useful, and it
certainly should ignore the index changing.
Thanks for the response, and sorry for the delay. I've sent a TCK patch to
adjust the test
https://www.redhat.com/archives/libvir-list/2020-March/msg00872.html
Regards,
Jim
