TCK regression from blockdev change

[Jim Fehlig]

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