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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list