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 :)