[Libvir] Some doubts for OpenVZ

[Shuveb Hussain]

On Fri, 2007-07-06 at 12:15 +0100, Richard W.M. Jones wrote:
> 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.

The "Defined domains" concept makes sense for OpenVZ. There can be many
VMs and only some among them may be active.


[...]

> == 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.

Looks like the libvirt config file for openvz will contain nothing else
but the UUIDs. This is definitely going to look weird!

> 
> > 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?

ID is an int and the name is a string. Earlier OpenVZ only had the VPS
IDs. Now it has both ID and name. The name I guess is optional. But
commonly people only use the ID, which is a number. Once assigned to a
VPS, it is there till the VPS is destroyed. It is not like a PID.

> 
> 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).
[...]

-- 
Shuveb Hussain

Unix is very user friendly. It is just a 
little choosy about who its friends are
http://www.binarykarma.com