[libvirt] [PATCH] openvz: swap <source bridge=...> with <target dev=...>

[Anton Protopopov]

2008/10/1 Anton Protopopov <aspsk2 at gmail.com>

> If openvz kernel requries specification of a NIC name for inside the
>> container, then this is an implemntation detail that the libvirt
>> OpenVZ driver will have to deal with. It can auto-assign them to be
>> eth0, eth1, etc. This is not exposed in the libvirt XML though, since
>> it is not relevant to the host admin, only apps inside the guest.
>
>
>
>>
>> > * absolutely ignore the <target dev=".."> in openvz XML description
>>
>> As I said before this needs to reflect the name of the interface on
>> the host side. It can be ignored when creating a guest, since for the
>> majority of uses cases it can be safely auto-generated. It must be
>> filled in when dumping XML for a guest, so the host admin knows which
>> NIC in the host corresponds to the guest.
>>
>
> Here is the patch, that implements the following behaviour
>
> * interface name inside container is automatically generated and equals
> ethN,
>    where N is the number of that interface within current domain
> * mac address of that interface inside container is generated automatically
> by
>    function openvzGenerateMac
> * if <target dev=""> is specified, use it; otherwise, use the default
> openvz name,
>    i.e., vethN.M for interface ethM in container with veid N
> * if <mac address='...'> specified, use it; otherwise, vzctl will generate
> it automatically
> * <target dev> and <mac address> are (re)stored (from)to $veid.conf
>
> Anton
>

Actually, I have some doubts about that patch: the functions
openvzGenerateMac and
openvzGenerateVethName are taken from vzctl sources and slightly changed
then. The problem
is that libvirt uses LGPL, while vzctl uses GPL. So you can't apply that
patch, right? Even if it is
good :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20081001/cb7cc492/attachment-0001.htm>