[Libvir] [RFC]OpenVZ XML def

Shuveb Hussain shuveb at gmail.com
Tue Mar 13 18:31:38 UTC 2007


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.




More information about the libvir-list mailing list