[libvirt] Add pool to domain xml

[Wout Mertens]

(Renamed subject from [PATCH] Support transient attribute on vmware disks)
On Dec 27, 2013, at 22:59 , Eric Blake <eblake at redhat.com> wrote:

> On 12/27/2013 02:40 PM, Wout Mertens wrote:
>> 
>> Otherwise it seems to me that this would be part of the general section, perhaps simply a “path” node?
> 
> Not quite a path node.  I was thinking more like:
> 
> <domain type='kvm'>
>  <name>foo</name>
>  <pool name='mypool'/>
>  ...
> 
> where the new <pool> element says that anything that the 'foo' domain
> does that requires creation of new files will do so within the already
> existing <pool> object with the name 'mypool'.  We can also support
> <pool uuid='...'> (or both name and uuid at once).  If the <pool>
> element is missing, that's when the domain uses defaults and/or refuses
> to do tasks where we don’t know where to stick the files.

Yes, that seems like a nice interface. It does throw away some info (the full path to the .vmx file in the case of VMWare) but that doesn’t really matter very much.

I had a look at implementing this but I’m stuck. I don’t know the code very well, I figure there are at least three places this impacts (for vmware):
- (1) the virDomainDef definition
- (2) the translation from virDomainDef to .vmx file path
- (3) (optionally I suppose) the translation from .vmx file to virDomainDef

For (1), I added a sub-struct to _virDomainDef in domain_conf.h:

    struct {
        char *name;
        char *uuid;
    } pool;

…thinking this would be easier than managing a pool object pointer and a more direct representation of the domain xml. Is there any change to definition or initialization code etc needed elsewhere? Testing code?

For (2): The translation from virDomainDef to path happens in vmware_conf.c:vmwareVmxPath() and there the problem is that regular VMWare uses a full path but ESX uses the ‘[storage] ‘ prefix instead.

- I presume there’s somewhere in the pool management code that translates this, any pointers?

- vmware_conf.c then needs to pull in the storage_conf.h file, is that a problem?

- I propose that if both UUID and name are present, UUID takes precedence over name, but if no device is found then name is tried.

I haven’t tackled (3) yet and I suppose it doesn’t really add much, certainly not for my use case.

Happy 2014! :)

Wout.