Hi Rich,
I think again we're entering into territory where virt-manager and other clients need to "just know" about the XML format and other quirks of the particular libvirt driver. That's not a high-level virtualisation API.
I have been thinking about that. OpenVZ is definitely very different from Xen or Qemu, which emulate whole machines. OpenVZ is just a container. There are so many tunable parameters for OpenVZ. Some of them are: * Max number of files that a VM can open * Max number of sockets * Max number of mmaped() pages * Guarunteed minimum CPU units * Maximum CPU units There are many other parameters. Please have a look at EasyVZ, an OpenVZ management GUI that I wrote. The screenshots are here: http://easyvz.sourceforge.net This will give you an idea of the tunable items that need to be presented to the user by any libvirt client for OpenVZ hosts. With the current scheme, this does not look possible. I also believe that the reason many people choose OpenVZ is because they can guarantee some amount of CPU power and memory to VMs and customers like it that way. These options must be provided by any client that manages OpenVZ based guests. I do not think that these options will hold any meaning when it comes to other VMs. So, how we go about keeping libvirt high level and still address these issues will be very interesting indeed.
Long email in preparation on this subject ... I won't spoil your anticipation.
Expecting this one soon :-) Regards, -- Shuveb Hussain. When you lose, be patient. When you achieve, be even more patient. EasyVZ: http://easyvz.sourceforge.net Blog: http://binarykarma.org