2008/10/3 Evgeniy Sokolov <evg(a)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?