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