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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list