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

[Jean-Baptiste Rouault]

On Thursday 09 December 2010 11:23:38 Daniel P. Berrange wrote:
> 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

As far as I know, it is possible to run 64-bit guests on a 32-bit host OS if 
there is a 64-bit CPU with vmx/svm so I think we don't care what the OS is in 
that case, don't we ?

> > > > +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.

Ok, I thought the connectGetType() API was there to give more information
than the name field if relevant because virConnectGetType() returns
driver->name when the type function isn't available.

Jean-Baptiste

-- 
Jean-Baptiste ROUAULT
Ingénieur R&D - Diateam : Architectes de l'information
Phone : +33 (0)9 53 16 02 70 Fax : +33 (0)2 98 050 051