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