[Libvir] [RFC]OpenVZ XML def
shuveb at gmail.com
Tue Mar 13 18:31:38 UTC 2007
> 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>126.96.36.199</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
> <interface type='bridge'>
> <ip address='192.168.1.101'
> 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.
I blog at http://binarykarma.org
Spread the Karma.
More information about the libvir-list