[Libvir] OpenVZ XML format and VPS properties get/set interface [long]

[Daniel Veillard]

On Mon, Jul 23, 2007 at 04:06:11PM +0530, Shuveb Hussain wrote:
> Hi,
> 
> I started a discussion on OpenVZ XML format a while ago. But let me do
> it again with more explanation about OpenVZ this time, so that others
> can understand how it is different and how this can best fit into the
> libvirt model of doing things.
> 
> Terminology: Virtual Private Server (VPS), Virtual Environment (VE) and
> Domain are all the same.
> 
> OpenVZ is a lot about providing QoS to its users. About 20 carefully
> chosen parameters regarding various resources such as memory, CPU, disk
> and network are chosen. These are then used to provide minimum guarantee
> on any system running OpenVZ. Most of the time, these are limits that
> can be set per Virtual Private Server(VPS). 
> 
> In Xen or QEMU, if a disk image is available(Xen needs an additional
> kernel), it is possible to run the domain. Then forget all about it
> after the domain is shutoff. This is not possible in OpenVZ. When a new
> VPS/VE/Domain needs to be created, it needs a file system. This needs to
> be created along with its related configuration files in specific
> locations. Only after this can it be started. There is a "destroy"
> command available in OpenVZ, which is different from the destroy in
> libvirt. This will completely erase the file system and remove the
> related config file as well.
> 
> Since there are many configurable parameters, the OpenVZ tools provides
> 2 sample templates or profiles on which newly created Virtual
> Environments(VEs) can be based. So, during VPS creation, rather than
> taking a million parameters, the name of the profile is taken as an
> argument and the variables in the file are used to create the VE. These
> values can later on be overridden and also be optionally stored in the
> VE's private config file to ensure persistence across reboots.
> 
> Since there are many parameters needed during VE creation, using the
> profile name is practical. So, in the proposed XML file, I'm using the
> profile name. 

  yes that sounds adequate to me.
I think that with both the template and the profile we have something
sufficient to get this to work. If needed we may later expand the format,
as long as the parsing code is well done it whould be backward and
forward compatible, just that the new elements may not be used by older
tools.

> OpenVZ has its own config file format. We are storing the UUID there in
> a comment, since UUIDs are not used by OpenVZ. While a VE is created,
> the easiest way to do it is using a so called template cache. This is
> just a tar file of a Linux distro FS that is used to create a new file
> system for a VE. There are no disk images. The VE root fs resides on the
> host file system as a bunch of files and directories. A few template
> caches are usually available, say one based on Debian, one based on
> Fedora Core and another based on Suse. The user can choose which one to
> use while creating a new VE. However, the name of the template cache is
> not stored anywhere once the VE filesystem is created. I think one more
> comment is needed in the per-VE config file for this, just as we are
> storing the UUID.
[...]
> Here is the proposed XML format:
> 
> <domain type='openvz'>
> <name>105</name>
> <uuid>8509a1d4-1569-4467-8b37-4e433a1ac7b1</uuid>
> <filesystem>
>     <template>gentoo-20060317-i686-stage3</template>
>     <quota level='first'>10737418240</quota>
>     <quota level='second' uid='500'>5368709120</quota>
> </filesystem>
> <profile>vps.basic</profile>
> <devices>
> <interface>
>     <ipaddress>192.168.1.105</ipaddress>
> </interface>
> </devices>
> <nameserver>192.168.1.1</nameserver>
> <hostname>fedora105</hostname>
> </domain>
> 
> I don't think the "filesystem" tag can fit logically into "devices",
> since it has quota and other information. The "template" is the name of
> the template cache used to create the VE.

  Hum, yes that is different from all other implementations so far.

But nameserver and hostname feels a bit misplaced. To me nameserver
should go somewhere else, it's kind of a duplicate of the networking stuff.
And what would happen if you have also IPv6, suddenly nameserver structure
breaks. I don't know yet how to best fix this but those two are problematic
as-is.
  
> One of the main reasons many people(especially hosting providers) use
> OpenVZ is since it can be used to provide service level agreements.
> There must be a way to set/get various VPS parameters from libvirt. I
> understand concerns about driver specific code in libvirt based clients
> like virt-manager. The capabilities paradigm will not fit here, since
> this is simply about various properties of the VE/domain, not the
> hardware or the VM capabilities. Please correct me, if I am wrong. So,
> how to we do it?

  piggy-back on virDomainGetSchedulerParameters/virDomainSetSchedulerParameters
that looks like the API flexible enough and closest in spirit.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/