[libvirt] [PATCH] Support transient attribute on vmware disks

Wout Mertens wout.mertens at gmail.com
Fri Dec 27 21:40:19 UTC 2013


OK… So what is the next step?

I just noticed the <metadata> node (http://libvirt.org/formatdomain.html#elementsMetadata), could that be used for this? E.g.
<metadata>
    <vpx:vmxpath xmlns:vpx=“http://libvirt.org/vmware/“>[foo] bar/bar.vmx</vpx:vmxpath>
</metadata>

Otherwise it seems to me that this would be part of the general section, perhaps simply a “path” node?

Wout.

On Dec 27, 2013, at 21:26 , Eric Blake <eblake at redhat.com> wrote:

> On 12/26/2013 04:02 PM, Wout Mertens wrote:
> 
>> Workarounds I can think of:
>> - Augment the domain xml description so it also defines the storage pool on which the created domain should reside
> 
> This is a good idea which I've wanted for other reasons - the qemu
> driver also has instances where we are sticking large files in a
> hard-coded directory (such as 'virsh managedsave') but where people have
> complained that they would like to control what directory gets used for
> it.  Adding an element to the <domain> xml that gives the name of the
> preferred virStoragePool for all operations requiring potentially large
> files associated with the domain is a change worth making.
> 
>> The first way seems the cleanest but is probably also the most work and touches more code.
> 
> Maybe, but it is the right thing to do.
> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131227/f054fe3e/attachment-0001.sig>


More information about the libvir-list mailing list