[libvirt] [Patch v3] Add VMware Workstation and Player driver

[Daniel P. Berrange]

On Thu, Dec 09, 2010 at 11:05:50AM +0100, Jean-Baptiste Rouault wrote:
> On Wednesday 08 December 2010 19:29:56 Daniel P. Berrange wrote:
> > 
> > FYI, you can still get CPUs which are 32-bit only and have vmx/svm
> > supported.
> 
> Indeed, I didn't know there were 32 bits CPUs with virtualization extensions.
> Would it be ok to check for the "lm" CPU flag to be certain that the host CPU
> is a 64bit one ?

You really want to check what the OS is running, not what the CPU is,
because you can put a 32-bit OS on a 64-bit CPU. Since VMware only
copes with x86 platforms you can use

  STREQ(utsname.machine, "x86_64") ? 64 : 32

> 
> > > +
> > > +        //vmrun list only reports running vms
> > > +        vm->state = VIR_DOMAIN_RUNNING;
> > > +        vm->def->id = driver->nextvmid++;
> > > +        vm->persistent = 1;
> > 
> > The VM ID is intended to be stable for the lifetime of a VM. It
> > seems like this could be unstable, depending on the order in
> > which vmrun -T returns the list. Is there any way to find a
> > more stable ID, even if it means using the VM's UNIX PID ?
> 
> I guess I could parse the first line of the VM log (file vmware.log in the vmx 
> directory) to get the PID.
> 
> > > +static const char *
> > > +vmwareGetType(virConnectPtr conn)
> > > +{
> > > +    struct vmware_driver *driver = conn->privateData;
> > > +    int type;
> > > +
> > > +    type = driver->type;
> > > +    return type == TYPE_PLAYER ? "vmware player" : "vmware workstation";
> > > +}
> > 
> > This should just be returning the same string that's
> > in the type field of the virDriverPtr struct that
> > was registered.
> 
> Do you mean the "name" field of the _virDriver struct ?

Yes.

Daniel