Re: [Libvir] [RFC]OpenVZ XML def
Hi,
In the Xen / QEMU drivers we just stick this as an 'id'
attribute on the top
level <domain> - it looks reasonable to follow the same scheme for OpenVZ
Sure, 'id' is good enough.
> <onboot>true</onboot>
Is this attribute refering to whether the guest auto-starts at boot
time ? If so we recently introduced an explicit API for querying and
changing this separately from the XML
int virDomainGetAutostart (virDomainPtr domain,
int *autostart);
int virDomainSetAutostart (virDomainPtr domain,
int autostart);
These APIs can be implmented per-driver
Yeah, you are right it does refers to auto-start at boot up time.
Then, I'll better ignore it in the XML def and implement the API stub
in the openVZ driver.
> <template>vps.basic</template>
> <os template='slackware-10.2-i386-minimal'/>
I'm not very familiar with way OpenVZ deals with OS installs / virtual
disk images. Could you explain a little how these map into underling
OpenVZ implementation - and what they end up doing on disk ?
OpenVZ is single kernel and multiple roof file sytems architecture.
Every VM has its root fs somewhere on the host, for example:
/vz/private/101 -> 101's root fs (containing bin,etc,usr,tmp,var,... )
/vz/private/102 -> 102's root fs (containing bin,etc,usr,tmp,var,... )
/vz/private/103 -> ......
These root file systems can be based on any Linux distro. The VM's
root fs is usually quickly created by untaring what is called a
template cache during VM creation time. A template cache is nothing
but a tar of a particular distro's root fs. There are these various
template caches available covering many popular Linux distros. While
creating a VM(or VPS, in OpenVZ jargon), one needs to the name of the
template cache that will be used to create the VM root file system.
There is a designated place where these template caches, basically tar
files, are kept. There is no disk image concept.
> <network>
> <hostname>openvzhost</hostname>
> <ip address='192.168.1.101'
> netmask='255.255.255.0'
> defgw='192.168.1.1'
> />
> <nameserver>192.168.1.1</nameserver>
> <nameserver>202.56.250.5</nameserver>
> </network>
For networking we need to figure out an XML format that more closely maps
to the existing network formats seen by Xen / QEMU drivers. Reading the
docs, the default networking config seems to map all OpenVZ guests onto
a 'venet0' bridge device which certainly has a common feel to Xen / QEMU.
It sounds like it is possible to do either manual or DHCP style address
configuration too. I think we need to express networking in a form closer
to something like
<devices>
<interface type='bridge'>
<hostname>openvzhost</hostname>
<ip address='192.168.1.101'
netmask='255.255.255.0'
gateway='192.168.1.1'
/>
<nameserver>192.168.1.1</nameserver>
<nameserver>202.56.250.5</nameserver>
</interface>
</devices>
You've probably guessed, that as a general rule we try to figure out XML
syntax that works in the same way across all backend drivers. Of course
OpenVZ has some unique concepts of its own which is fine, but other areas
like networking does share some level of common semantics so where possible
we should take advantage of the commonality.
Yeah, that was my aim too. Not to be too different from the existing
XML defs. This should not be an issue at all.
--
Shuveb Hussain.
I blog at http://binarykarma.org
Spread the Karma.