[Libvir] [RFC]OpenVZ XML def

Shuveb Hussain 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=''
> >          netmask=''
> >          defgw=''
> >      />
> >      <nameserver></nameserver>
> >      <nameserver></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=''
>                netmask=''
>                gateway=''
>             />
>             <nameserver></nameserver>
>             <nameserver></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.

More information about the libvir-list mailing list