2008/10/3 Evgeniy Sokolov <evg@openvz.org>
Hi.
I rewrite functions taken from vzctl in the new patch, so this:
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
is true, while that:
the functions openvzGenerateMac and openvzGenerateVethName are taken from vzctl sources and slightly changed then
is not true anymore.
+static char * +openvzGenerateMac(void) +{ + char mac[6] = { + 0x52, + 0x54, + 0x00, How did you get 0x52, 0x54, 0x00?
This is the same as in virDomainNetRandomMAC() function, see the source code for it.
+ if (net->type == VIR_DOMAIN_NET_TYPE_BRIDGE) { + static int vnetNo = 0;
Libvirt may be use as library in applications. If some will call create 2 containers, then first container will have eth0...ethN second will have ethN+1...
OK, I will try to fix it.
Other looks good.
Actually, there is a bug :( When we generate host interface name, we need to save it in net->ifname. P.S. Now I am working on that:
P.S. Are someone going to implement <interface type='bridge'> ... <source bridge="..."> ... </interface> part of openvz driver? :)
I plan to implement it in a month. It will be fine if you are ready to develop the feature.
I'm using $veid.conf to store information about bridge device in the following manner: for interface <ifname>, therhe will be a line #BRIGDE(<ifname>): <bridge name> for example, #BRIDGE(veth101.0): virbr1 Do you agree with that behaviour?