On Mon, 2007-07-23 at 12:33 +0100, Richard W.M. Jones wrote: > Shuveb Hussain wrote: > > In Xen or QEMU, if a disk image is available(Xen needs an additional > > kernel), it is possible to run the domain. Then forget all about it > > after the domain is shutoff. This is not possible in OpenVZ. When a new > > VPS/VE/Domain needs to be created, it needs a file system. This needs to > > be created along with its related configuration files in specific > > locations. Only after this can it be started. There is a "destroy" > > command available in OpenVZ, which is different from the destroy in > > libvirt. This will completely erase the file system and remove the > > related config file as well. > > It sounds like OpenVZ "destroy" goes beyond "virsh undefine". The > latter just removes the config file, and that can be recreated fairly > easily. > > Is it common to destroy OpenVZ domains? What happens to all the guest's > local configuration (changes to /etc, /home)? The whole guest FS is destroyed, nothing is backed up! [...] > So my understanding is this: the debate would be about whether we want > these parameters to be visible in the XML file, or is it better to have > them hidden in a OpenVZ-specific file. Also, how do these parameters > relate to other systems (eg. Xen scheduler parameters). Yeah Richard, this is what I am wondering about. > > I don't have good answers to these ... :-( > > I did notice that OpenVZ uses a replacement / enhancement of BSD > resource limits called CONFIG_BEANCOUNTER. What's the status of just > this patch w.r.t. upstream Linux kernel? User Beancounters have been proposed by SWSoft for the Linux kernel, but AFAIK, nothing is sitting in the mainline. And in the meantime a lot of activity is going on in the Containers area, especially by Rohith Seth and Paul Manage of Google. It is difficult to predict what will get merged. OpenVZ as such definitely won't get merged, due to its style, size and treatment. The OpenVZ hackers are OK with this, I guess. [...] > This is the first virtualisation system I've seen that uses direct > access to a chrooted filesystem on the host. All the ones we've > considered before have used disk images or partitions. I'm guessing > however that things like BSD jails & OpenSolaris containers are similar > to OpenVZ? So it's worth considering in some detail how this is going > to work. May be. I haven't looked into BSD Jails and OpenSolaris containers. I wonder what management interfaces they provide. Depends where OpenVZ was inspired from ;-) > Should we simply specify in the XML file the location of the filesystem, > and assume that something else creates it? (I'm sure that will be > complicated in the OpenVZ case, but it may allow admins to use, for > example, debootstrap to set up root filesystems by hand). > > Something like: > <filesystems> > <filesystem root="/mnt/guest1" /> > </filesystems> > > Where we want guest creation to create the filesystem as well: > > <filesystems> > <filesystem root="/mnt/guest1" > template="/templates/gentoo-xyz-stage3" /> > </filesystems> > > (I notice that the OpenVZ description doesn't say either (1) where the > filesystem will be created, nor (2) where the template file is located. > There is no way we can specify where we want the new root file system to get created. There is a specific location where all VE file systems get created, for example: /vz/private/101 -> root fs base for VPS 101 /vz/private/102 -> root fs base for VPS 102 /vz/private/103 -> root fs base for VPS 103 ... The templates caches are in the location /vz/template/cache. The base /vz itself maybe in other locations on some distros. But when you specify the template name to the OpenVZ tools to create a VM, it will pick the template cache archive file from the correct location. For example, this command creates a new VPS with ID 105: # vzctl create 105 --ostemplate fedora-core-4 -–config vps.basic So, I guess we'll need to keep the "filesystem" tag out of the "devices" section. Or, are there other thoughts? Thanks, -- 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