[virt-tools-list] [virt-manager PATCH] test: Fix tests with latest libvirt

[Cole Robinson]

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 at 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