[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] [RFC]OpenVZ XML def



On Tue, Mar 13, 2007 at 10:57:23PM +0530, Shuveb Hussain wrote:
> Hi,
> I am adding OpenVZ support to Libvirt and work is progressing well.
> I'm able to list VM instances and I'm slowly trying to cover the basic
> API functions one by one. That brings  us to the creation of OpenVZ
> based VMs. Just wanted to discuss the basic XML definition format so
> that I can get comments and improve if need be:
> 
> <domain type='openvz'>
>  <name>openvzdemo</name>
>  <uuid>55a2441d-e012-40fe-a4f7-78e176015d40</uuid>
>  <vpsid>101</vpsid>

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

>  <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

>  <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 ? 

>  <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.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]