2008/10/1 Anton Protopopov <aspsk2(a)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 :)