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

On Fri, Jul 06, 2007 at 04:09:40PM +0530, Shuveb Hussain wrote:

Hi,

I have some basic doubts.

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. Is there a necessity to have per-vm config files in libvirt for the OpenVZ VMs? 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?

No, we definitely need UUIDs. If there's no way to associate extra metadata with Open VZ configs, then probably best to try and come up with a way to map a UUID to a OpenVZ guest via an extranal file. At simplest I guess you could have a directly containing 1 file per VM, and each file merely contain the 16 byte UUID. Or maybe there's a way to deterministically generate a UUID based on some other piece of data. eg, take a 14 byte UUID for the host and add in 2 bytes per VM from its VPS ID to form a 16 byte UUID for the VM. That might allow you to form a UUID without needing to store it anywhere.

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?

There is no defined rule that says 'id' has to be temporary, so I think you can probably use 'VPS ID' as your 'id' value. Basically the difference between 'id', 'name' and 'uuid' is all todo with uniqueness - ID is required to be unique amongst any active virtual machines on a single host - Name is required to be unique amongst any active or inactive virtual machines on a single host - UUID is required to be unique amongst all virtual machines in the world Now it sounds like 'VPS ID' is more unique than neccessary, but that's not a problem. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|