8:20 a.m.
On 05/04/2014 10:59 PM, Chen Hanxiao wrote:
Signed-off-by: Chen Hanxiao <chenhanxiao(a)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
12:03 p.m.
New subject: [libvirt] [virt-tools-list] [virt-manager PATCH] test: Fix tests with latest libvirt
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(a)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
12:03 p.m.
New subject: [libvirt] [virt-tools-list] [virt-manager PATCH] test: Fix tests with latest libvirt
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(a)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
3857
days inactive
3857
days old
2 comments
2 participants
participants (2)
-
Cole Robinson -
Eric Blake