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

Re: [libvirt] xml format for openvz driver

On Thu, Jul 24, 2008 at 11:48:16AM +0400, Evgeniy Sokolov wrote:
> I just want to summarize
> XML for OpenVZ will looks like
> <domain type='openvz'>
>         <name>209</name>
>         <uuid>8dea22b31d52d8f32516782e98ab8fa0</uuid>
>         <devices>
>                 <filesystem type="template">
>                         <source name="fedora-core-5-i386" />

THis will also get an element:

                         <target dir="/"/>

>                         <quota type="size" max="10000"/>
>                         <quota type="inodes" max="200000"/>
>                 </filesystem>

>                 <interface type='bridge'> //for bridge
> 	                <source bridge='eth10'/>
>                         <mac address='00:16:3e:5d:c7:9e'/>
>                 </interface>

This is good.

>                 <interface type='bridge'> //for NAT
> 	                 <source bridge='eth11'/>
> 	                 <target type='network'>
>                                  <source network='default'/>
>                          </target>
>                 </interface>

I think you mis-understood how I described this previously. The libvirt
NAT networking works like this:

      <interface type='network'>
        <source network='default'/>
        <mac address="11:22:33:44:55:66"/>

>                 <interface type='network'> //for phisical device
> 	                 <host class='network' dev='eth1'/>
>                 </interface>

I'm not sure about this - I think I'd still like host device passthough
to be an explicit type of device:

        <host class='network' subsys='pci'>
           <source name='eth0'/>
           <address domain="0000" bus="00" slot="1f" function="3"/>

With either the 'class' or 'subsys' properties being required.
Given one, libvirt can fill in the other as needed. If 'class'
is provided, then the <source> element should be used too. If
'subsys' is provided, then <address> provides the hardware 
device address. This information will all be available directly
from the host device enumeration APIs, so we'll want to have a
clearly defined mapping between the domain XML for a host device
and the host device XML


>                 <interface type='route'> //for routing network
> 	                 <mac address='00:16:3e:34:21:9e'/>
>                          <ip address="" />
>                          <ip address="" />
>                 </interface>

This is basically the generic type='ethernet' that we already have,
but with a few more  properties available, so I don't thing there's
need for a new type='route'

|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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