[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


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. 

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 a sample template. This one is called vps.basic, comes with the
OpenVZ tools:

# UBC parameters (in form of barrier:limit)
# Primary parameters
# Secondary parameters
# Auxiliary parameters


# Disk quota parameters (in form of softlimit:hardlimit)

# CPU fair sheduler parameter

Here is the proposed XML format:

<domain type='openvz'>
    <quota level='first'>10737418240</quota>
    <quota level='second' uid='500'>5368709120</quota>

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.

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?

Thanks and Regards,
Shuveb Hussain

Unix is very user friendly. It is just a 
little choosy about who its friends are

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]