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