Re: [Libvir] OpenVZ XML format and VPS properties get/set interface [long]
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)?
[...]
Here is a sample template. This one is called vps.basic, comes with
the
OpenVZ tools:
-----------------------------------------------------------------
ONBOOT="no"
# UBC parameters (in form of barrier:limit)
# Primary parameters
AVNUMPROC="40:40"
NUMPROC="65:65"
NUMTCPSOCK="80:80"
NUMOTHERSOCK="80:80"
VMGUARPAGES="6144:2147483647"
# Secondary parameters
KMEMSIZE="2752512:2936012"
TCPSNDBUF="319488:524288"
TCPRCVBUF="319488:524288"
OTHERSOCKBUF="132096:336896"
DGRAMRCVBUF="132096:132096"
OOMGUARPAGES="6144:2147483647"
# Auxiliary parameters
LOCKEDPAGES="32:32"
SHMPAGES="8192:8192"
PRIVVMPAGES="49152:53575"
NUMFILE="2048:2048"
NUMFLOCK="100:110"
NUMPTY="16:16"
NUMSIGINFO="256:256"
DCACHESIZE="1048576:1097728"
PHYSPAGES="0:2147483647"
NUMIPTENT="128:128"
# Disk quota parameters (in form of softlimit:hardlimit)
DISKSPACE="1048576:1153434"
DISKINODES="200000:220000"
QUOTATIME="0"
# CPU fair sheduler parameter
CPUUNITS="1000"
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).
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?
Here is the proposed XML format:
<domain type='openvz'>
<name>105</name>
<uuid>8509a1d4-1569-4467-8b37-4e433a1ac7b1</uuid>
<filesystem>
<template>gentoo-20060317-i686-stage3</template>
<quota level='first'>10737418240</quota>
<quota level='second' uid='500'>5368709120</quota>
</filesystem>
<profile>vps.basic</profile>
<devices>
<interface>
<ipaddress>192.168.1.105</ipaddress>
</interface>
</devices>
<nameserver>192.168.1.1</nameserver>
<hostname>fedora105</hostname>
</domain>
I don't think the "filesystem" tag can fit logically into
"devices",
since it has quota and other information. The "template" is the name of
the template cache used to create the VE.
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.
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.
Just thoughts ... sorry that I don't have good answers here :-(
Rich.