[Libvir] Some doubts for OpenVZ

[Richard W.M. Jones]

Shuveb Hussain wrote:
> 1. The OpenVZ system has one config file per VM which contains all the
> VM's parameters. So, during libvirt start-up, these files can be read,
> or openvz utils can be popened() to get information regarding these VMs.

It's not very well explained, but libvirt has a number of design 
concepts which are directly influenced by Xen, for better and sometimes 
for worse.  I'll explain them here, since they seem to relate to your 
question.

== "Defined" domains ==

In old versions of Xen (pre 3.0.4 I think?) you would have one config 
file in /etc/xen for each domain (eg. /etc/xen/database-config.sxp for a 
virtual machine called "database").  This config file would define 
amongst other things the memory to allocate to the domain, the disk 
image it uses and so on.

Now, a domain can be shutdown, or it can be running.  In Xen/libvirt 
terminology a domain which had a config file but which _isn't_ running 
is called "inactive" or a "defined domain".  For older Xen, the file 
src/xm_internal.c contains the code which reads the config files and 
looks for defined domains, and more importantly _writes_ to the config 
files on certain actions.  I think for OpenVZ you may want to start by 
looking at this file.

In more recent versions of Xen, the implementation of this changed and 
now the config files under /etc/xen, if they are there at all, are only 
used the first time you ever start a domain.  After that, Xen keeps the 
configuration hidden in its own private place.  We have to go through 
the xend daemon to find out all information about domains, whether 
defined or running.

This is also the reason why the recommended way to change the 
configuration of a domain is not to edit a config file, but to use:

   virsh dumpxml dom > dom.xml
   edit dom.xml
   virsh define dom.xml

It's because we are dealing with Xen wierdness.

== UUIDs ==

You could also specify a UUID (either in the config file for old Xen, or 
Xen allocates one in new Xen), and the UUID persists across reboots, so 
it is supposed to uniquely, globally identify that domain for all time.

(As a side note, in Xen 3.0.2 you didn't need to put the UUID in that 
config file, but Xen still somehow assigns UUIDs to domains).

> Is there a necessity to have per-vm config files in libvirt for the
> OpenVZ VMs?

I would start by looking at src/xm_internal.c, since OpenVZ sounds a lot 
like the "old Xen" way of doing things.

 > I understand UUIDs are used to identify each of the running
> VMs. Where will these values persist? Can I do away with UUIDs for
> OpenVZ and avoid the libvirt specific config file?

Libvirt relies on UUIDs, so you need to find a way to allocate a UUID 
for the full lifetime of an OpenVZ domain.  That may be stored in the 
config file, if possible, or stored somewhere else.

> 2. In OpenVZ, there is just a VPS ID/Name. There is no temporary
> reference like 'id'. For example QEMU is using the process PID. There is
> no such notion for OpenVZ. In that case, can I make 'name' and 'id' same
> for OpenVZ?

What is VPS ID/Name?  Is it a string?  Number?

Again, libvirt conceptually needs a domain ID, which must be an integer. 
  It's different from UUID in that domain IDs can be and are reused 
(they are a lot like PIDs).

As an aside, in Xen domain IDs are 16 bit integers.  It's not clear what 
happens when they wrap around, but in my testing I've hit dom IDs > 1000 
several times, so it would probably only take a week or two of 
continuous testing before they wrap around.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070706/51fd8275/attachment-0001.bin>