[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