Re: [Libvir] OpenVZ XML format and VPS properties get/set interface [long]
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