Re: [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&gt; >> --- >> 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.