Re: [libvirt] [virt-tools-list] [virt-manager PATCH] test: Fix tests with latest libvirt
On 05/04/2014 10:59 PM, Chen Hanxiao wrote:
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com> --- tests/cli-test-xml/compare/virt-clone-clone-auto1.xml | 6 ++++++ tests/cli-test-xml/compare/virt-clone-clone-auto2.xml | 1 + 2 files changed, 7 insertions(+)
diff --git a/tests/cli-test-xml/compare/virt-clone-clone-auto1.xml b/tests/cli-test-xml/compare/virt-clone-clone-auto1.xml index b9fde61..03b7b5c 100644 --- a/tests/cli-test-xml/compare/virt-clone-clone-auto1.xml +++ b/tests/cli-test-xml/compare/virt-clone-clone-auto1.xml @@ -22,16 +22,19 @@ <disk type="block" device="floppy"> <driver type="vmdk"/> <source dev="/dev/disk-pool/diskvol1-clone"/> + <backingStore/> <target dev="fda" bus="fdc"/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk> <disk type="block" device="disk"> <source dev="/dev/disk-pool/diskvol2"/> + <backingStore/> <target dev="sda" bus="scsi"/> <readonly/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk> <disk type="block" device="cdrom"> + <backingStore/> <target dev="sdb" bus="scsi"/> <readonly/> <address type="drive" controller="0" bus="0" target="0" unit="1"/> @@ -39,6 +42,7 @@ <disk type="block" device="disk"> <driver type="qcow2"/> <source dev="/dev/default-pool/collidevol1.img"/> + <backingStore/> <target dev="sdc" bus="scsi"/> <readonly/> <shareable/> @@ -46,11 +50,13 @@ </disk> <disk type="file" device="disk"> <source file="/dev/default-pool/default-vol-clone"/> + <backingStore/> <target dev="hda" bus="ide"/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk> <disk type="file" device="disk"> <source file="/dev/default-pool/testvol2-clone.img"/> + <backingStore/> <target dev="hdb" bus="ide"/> <address type="drive" controller="0" bus="0" target="0" unit="1"/> </disk> diff --git a/tests/cli-test-xml/compare/virt-clone-clone-auto2.xml b/tests/cli-test-xml/compare/virt-clone-clone-auto2.xml index fb78434..bbbde76 100644 --- a/tests/cli-test-xml/compare/virt-clone-clone-auto2.xml +++ b/tests/cli-test-xml/compare/virt-clone-clone-auto2.xml @@ -22,6 +22,7 @@ <disk type="file" device="disk"> <driver type="qcow2"/> <source file="/dev/default-pool/newvm.img"/> + <backingStore/> <target dev="hda" bus="ide"/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk>
Hmm, what is actually going on here? I know latest libvirt added backingStore chain XML to the domain XML, but what does a bare <backingStore/> mean here? Anyone on the libvirt side know if this is intentional? - Cole
On 05/05/2014 07:20 AM, Cole Robinson wrote:
On 05/04/2014 10:59 PM, Chen Hanxiao wrote:
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com> --- tests/cli-test-xml/compare/virt-clone-clone-auto1.xml | 6 ++++++ tests/cli-test-xml/compare/virt-clone-clone-auto2.xml | 1 + 2 files changed, 7 insertions(+)
+++ b/tests/cli-test-xml/compare/virt-clone-clone-auto2.xml @@ -22,6 +22,7 @@ <disk type="file" device="disk"> <driver type="qcow2"/> <source file="/dev/default-pool/newvm.img"/> + <backingStore/> <target dev="hda" bus="ide"/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk>
Hmm, what is actually going on here? I know latest libvirt added backingStore chain XML to the domain XML, but what does a bare <backingStore/> mean here?
A bare <backingStore/> is intentional - it means "known end of chain". In concrete terms, this XML <disk type="file" device="disk"> <driver type="qcow2"/> <source file="file1"> <target dev="hda" bus="ide"/> </disk> represents a qcow2 file that might or might not have a backing file (we haven't probed it yet), while this XML <disk type="file" device="disk"> <driver type="qcow2"/> <source file="file1"> <backingStore/> <target dev="hda" bus="ide"/> </disk> explicitly represents a qcow2 file with no backing store. The distinction is present to allow for smooth upgrade from older libvirt which didn't record backing information to new libvirt; in particular, we want to eventually get to a point where the user has full control over the backing chain at domain definition time (in 1.2.4, the information is output only, but we are still working on getting the information to also be parsed on input for 1.2.5).
Anyone on the libvirt side know if this is intentional?
Yes. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 05/05/2014 01:03 PM, Eric Blake wrote:
On 05/05/2014 07:20 AM, Cole Robinson wrote:
On 05/04/2014 10:59 PM, Chen Hanxiao wrote:
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com> --- tests/cli-test-xml/compare/virt-clone-clone-auto1.xml | 6 ++++++ tests/cli-test-xml/compare/virt-clone-clone-auto2.xml | 1 + 2 files changed, 7 insertions(+)
+++ b/tests/cli-test-xml/compare/virt-clone-clone-auto2.xml @@ -22,6 +22,7 @@ <disk type="file" device="disk"> <driver type="qcow2"/> <source file="/dev/default-pool/newvm.img"/> + <backingStore/> <target dev="hda" bus="ide"/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk>
Hmm, what is actually going on here? I know latest libvirt added backingStore chain XML to the domain XML, but what does a bare <backingStore/> mean here?
A bare <backingStore/> is intentional - it means "known end of chain". In concrete terms, this XML
<disk type="file" device="disk"> <driver type="qcow2"/> <source file="file1"> <target dev="hda" bus="ide"/> </disk>
represents a qcow2 file that might or might not have a backing file (we haven't probed it yet), while this XML
<disk type="file" device="disk"> <driver type="qcow2"/> <source file="file1"> <backingStore/> <target dev="hda" bus="ide"/> </disk>
explicitly represents a qcow2 file with no backing store. The distinction is present to allow for smooth upgrade from older libvirt which didn't record backing information to new libvirt; in particular, we want to eventually get to a point where the user has full control over the backing chain at domain definition time (in 1.2.4, the information is output only, but we are still working on getting the information to also be parsed on input for 1.2.5).
Anyone on the libvirt side know if this is intentional?
Yes.
Sounds good, thanks for clarifying. - Cole
participants (2)
-
Cole Robinson -
Eric Blake