[libvirt] [RFC] Network interface XML for containers

[Dave Leskovec]

Daniel P. Berrange wrote:
> On Fri, May 09, 2008 at 10:16:38AM -0700, Dave Leskovec wrote:
>> We never really settled on the XML format for container network interfaces.  I
>> know a little more about what these look like now and have been working on the
>>  code so would like to get this sorted out.

...

>>
>> Network or bridge name
>> Name for parent side veth device
>> Name for container side veth device
> 
> Do you really need to be able to specify the guest side of the NIC
> name in the XML ? I'd rather we just left it out unless there was a
> clear need & it can't be automatically determined by the driver. With
> other virt drivers, the guest side of the NIC just gets name sequentially
> assigned eth0, eth1,...  Linux lets you rename the NICs anyway so IMHO
> the only important thing is the MAC address since that's guarenteeed
> persistent & unique property for NICs, which a name is not.

No the guest side doesn't necessarily have to be specified.  It will get
auto-assigned.  The interface for creating veth devices (ip link add type veth)
 does make it difficult to determine the names it assigned.  It does not print
the names of the new devices and running a second command to get them is
problematic.  Hmmmm...  also doesn't seem to like specifying just one of the
device names but is fine if you specify both.  I'm all for not specifying the
guest side if I can make it work.

> 
>> inet address for container side veth device
> 
> Again, why are you specifying an IP address manually ? THe guest IP is 
> typically determined by the guest admin, either statically  or via DHCP.
> It shouldn't need to be configured in the host side if using the libvirt
> virtual networking or bridging.

So the users init would be responsible for configuring the container veth device
then?  At that point they can assign a static ip if desired?  This would mean
that for a container that wanted to just run an application, <init> would have
to point to a script that configured the network and then ran the application.
Not sure that's a problem, just stating the consequence.

> 
>> So this should end up looking quite a bit like the formats for Virtual network
>> and Bridge to LAN with a couple new items.  The formats I've been kicking around
>> are:
>> Virtual network
>>     <devices>
>>         <interface type='network'>
>>             <source network='default' dev='veth0'/>
>>             <target dev='veth1' address='192.168.0.150'/>
>>         </interface>
>>     </devices>
> 
> Due to a historical accident the <target> element in the interface
> XML is actually refering to the host side of the NIC. We don't have
> any existing element in our XML format describing the guest name of
> the NIC - its just implied by ordering. THe <target> element is
> also treated as read-only by existing drivers, being automagically
> assigned unique name by the virt driver.

Ah, ok.

> 
> The containers should follow the existing XML format 100%
> 
>         <interface type='network'>
>             <source network='default'>
>             <target dev='veth0'/>
>         </interface>
> 

Right.  I agree, this is what I'd like to see.

>> Bridge to LAN
>>     <devices>
>>         <interface type='bridge'>
>>             <source bridge='virbr0' dev='veth4'/>
>>             <target dev='veth5' address='192.168.0.155'/>
>>         </interface>
>>     </devices>
> 
> Again I think including the guest NIC name is redundant, likewise for 
> ip address & we can follow the existing XML format 100%
> 
>         <interface type='bridge'>
>             <source network='br0'>
>             <target dev='veth4'/>
>         </interface>

Yep.

-- 
Best Regards,
Dave Leskovec
IBM Linux Technology Center
Open Virtualization