Re: TCK regression from blockdev change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux