On 01/02/2014 02:58 AM, Wout Mertens wrote:
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,
That's okay; keep asking questions here or on IRC, and we can try and
help guide you.
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?
Yes, that actually looks like the right way to do it. For adding new
XML, you'll also want to touch at least docs/formatdomain.html.in to
document it, docs/schemas/domaincommon.rng to let virt-xml-validate
accept it, and add something to the testsuite (I often add things in
tests/qemuxml2argvdata, but as your implementation is targeting vmware
rather than qemu, that doesn't have to be your first choice).
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?
I'm not as familiar with the vmware storage driver, so we're both
learning here.
- vmware_conf.c then needs to pull in the storage_conf.h file, is that a problem?
Should be okay.
- 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.
If both are present, then the matching pool must match on both attributes.
I haven’t tackled (3) yet and I suppose it doesn’t really add much, certainly not for my
use case.
Happy 2014! :)
Wout.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org