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