5:17 a.m.
2008/9/29 Evgeniy V. Sokolov <evg(a)parallels.com>
> This behaviour contradicts with description found in docs (in which
> <source> tag specify interface in host, not in container). I think,
> the previous bridge must be specified as
> <interface type='bridge'>
> <mac address='00:16:3e:34:21:9e'/>
> - <source bridge='eth10'/>
> + <target dev='eth10'/>
> </interface>
>
> You are right. It is bug.
>
> Well, here is the patch, that fixes that behaviour.
>
Your patch is half of fix. It require to fix openvzReadNetworkConf() in
openvz_conf.c.
Here is a new one. Check it, please.
7:11 a.m.
2008/9/29 Evgeniy V. Sokolov <evg(a)parallels.com
<mailto:evg@parallels.com>>
This behaviour contradicts with description found in docs
(in which
<source> tag specify interface in host, not in
container). I think,
the previous bridge must be specified as
<interface type='bridge'>
<mac address='00:16:3e:34:21:9e'/>
- <source bridge='eth10'/>
+ <target dev='eth10'/>
</interface>
You are right. It is bug.
Well, here is the patch, that fixes that behaviour.
Your patch is half of fix. It require to fix openvzReadNetworkConf() in
openvz_conf.c.
Here is a new one. Check it, please.
Patch looks good.
But currently it will work strange because of all drivers (except
OpenVZ) in libvirt require specified <source bridge=""/> - it is generic.
With patch you need to specify both
<source bridge='eth10'/> - to satisfy common requirements
<target dev='eth10'/> - to create network
7:13 a.m.
On Mon, Sep 29, 2008 at 04:11:39PM +0400, Evgeniy Sokolov wrote:
>2008/9/29 Evgeniy V. Sokolov <evg(a)parallels.com
<mailto:evg@parallels.com>>
>
>
>
> This behaviour contradicts with description found in docs
> (in which
> <source> tag specify interface in host, not in
> container). I think,
> the previous bridge must be specified as
> <interface type='bridge'>
> <mac address='00:16:3e:34:21:9e'/>
> - <source bridge='eth10'/>
> + <target dev='eth10'/>
> </interface>
>
> You are right. It is bug.
>
> Well, here is the patch, that fixes that behaviour.
>
>
> Your patch is half of fix. It require to fix openvzReadNetworkConf() in
> openvz_conf.c.
>
>
>Here is a new one. Check it, please.
Patch looks good.
But currently it will work strange because of all drivers (except
OpenVZ) in libvirt require specified <source bridge=""/> - it is
generic.
With patch you need to specify both
<source bridge='eth10'/> - to satisfy common requirements
<target dev='eth10'/> - to create network
That is not right. The <target> element *must* be optional when creating
a new domain. If omitted, the driver must generated a suitable target
dev according to its desired naming scheme. Only the <source> element
can be compulsory
Daniel.
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
7:24 a.m.
On Mon, Sep 29, 2008 at 04:11:39PM +0400, Evgeniy Sokolov wrote:
>> 2008/9/29 Evgeniy V. Sokolov <evg(a)parallels.com
<mailto:evg@parallels.com>>
>>
>>
>>
>> This behaviour contradicts with description found in docs
>> (in which
>> <source> tag specify interface in host, not in
>> container). I think,
>> the previous bridge must be specified as
>> <interface type='bridge'>
>> <mac address='00:16:3e:34:21:9e'/>
>> - <source bridge='eth10'/>
>> + <target dev='eth10'/>
>> </interface>
>>
>> You are right. It is bug.
>>
>> Well, here is the patch, that fixes that behaviour.
>>
>>
>> Your patch is half of fix. It require to fix openvzReadNetworkConf() in
>> openvz_conf.c.
>>
>>
>> Here is a new one. Check it, please.
> Patch looks good.
> But currently it will work strange because of all drivers (except
> OpenVZ) in libvirt require specified <source bridge=""/> - it is
generic.
> With patch you need to specify both
> <source bridge='eth10'/> - to satisfy common requirements
> <target dev='eth10'/> - to create network
That is not right. The <target> element *must* be optional when creating
a new domain. If omitted, the driver must generated a suitable target
dev according to its desired naming scheme. Only the <source> element
can be compulsory
Agree with you. You say about "how should it be". I say about "how is it
now".
Currenty OpenVZ driver don't generate device name - my mistake.
Daniel.
7:57 a.m.
2008/9/29 Evgeniy Sokolov <evg(a)openvz.org>
On Mon, Sep 29, 2008 at 04:11:39PM +0400, Evgeniy Sokolov wrote:
>
>> 2008/9/29 Evgeniy V. Sokolov <evg(a)parallels.com <mailto:
>>> evg(a)parallels.com>>
>>>
>>>
>>>
>>> This behaviour contradicts with description found in docs
>>> (in which
>>> <source> tag specify interface in host, not in
>>> container). I think,
>>> the previous bridge must be specified as
>>> <interface type='bridge'>
>>> <mac address='00:16:3e:34:21:9e'/>
>>> - <source bridge='eth10'/>
>>> + <target dev='eth10'/>
>>> </interface>
>>>
>>> You are right. It is bug.
>>>
>>> Well, here is the patch, that fixes that behaviour.
>>>
>>>
>>> Your patch is half of fix. It require to fix openvzReadNetworkConf()
>>> in
>>> openvz_conf.c.
>>>
>>>
>>> Here is a new one. Check it, please.
>>>
>> Patch looks good.
>> But currently it will work strange because of all drivers (except OpenVZ)
>> in libvirt require specified <source bridge=""/> - it is
generic.
>> With patch you need to specify both
>> <source bridge='eth10'/> - to satisfy common requirements
>> <target dev='eth10'/> - to create network
>>
>
> That is not right. The <target> element *must* be optional when creating
> a new domain. If omitted, the driver must generated a suitable target
> dev according to its desired naming scheme. Only the <source> element
> can be compulsory
>
Agree with you. You say about "how should it be". I say about "how is it
now".
Currenty OpenVZ driver don't generate device name - my mistake.
Is vnet$i (where $i is the number of automatically generated interface
name for this container) appropriate?
>
> Daniel.
>
8:22 a.m.
On Tue, Sep 30, 2008 at 04:57:15PM +0400, Anton Protopopov wrote:
2008/9/29 Evgeniy Sokolov <evg(a)openvz.org>
>
> On Mon, Sep 29, 2008 at 04:11:39PM +0400, Evgeniy Sokolov wrote:
>>
>>> 2008/9/29 Evgeniy V. Sokolov <evg(a)parallels.com <mailto:
>>> Patch looks good.
>>> But currently it will work strange because of all drivers (except OpenVZ)
>>> in libvirt require specified <source bridge=""/> - it is
generic.
>>> With patch you need to specify both
>>> <source bridge='eth10'/> - to satisfy common requirements
>>> <target dev='eth10'/> - to create network
>>>
>>
>> That is not right. The <target> element *must* be optional when creating
>> a new domain. If omitted, the driver must generated a suitable target
>> dev according to its desired naming scheme. Only the <source> element
>> can be compulsory
>>
>
> Agree with you. You say about "how should it be". I say about "how is
it
> now".
> Currenty OpenVZ driver don't generate device name - my mistake.
Is vnet$i (where $i is the number of automatically generated interface
name for this container) appropriate?
Possibly, though its not terribly consistent so far.
Xen - vifNNN.MMM (NNN dom ID, MMM = nic number)
QEMU - vnetNNN (NNN = global host nic number)
LXC - vethNNN (MMM = global host nic number)
We can't change the format Xen uses, but it could be desirable to make
LXC, QEMU and OpenVZ all use vnetNNN scheme by default for auto assigned
nics names on the host side.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
8:57 a.m.
Possibly, though its not terribly consistent so far.
Xen - vifNNN.MMM (NNN dom ID, MMM = nic number)
QEMU - vnetNNN (NNN = global host nic number)
LXC - vethNNN (MMM = global host nic number)
And how these drivers choose NNN? Do QEMU driver and LXC driver use the same
NNN?
We can't change the format Xen uses, but it could be desirable to make
LXC, QEMU and OpenVZ all use vnetNNN scheme by default for auto assigned
nics names on the host side.
Now openvz driver chooses not interface name in host, but interface name in
container.
(If you specify contaner-ifname, say, vnet4, you get host-ifname
veth$veid.4.)
So first we need to decide: is container-ifname derivative from host-ifname
or vice versa :)
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/:|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org:|
|: http://autobuild.org -o-
http://search.cpan.org/~danberr/<http://search.cpan.org/%7Edanberr/>:|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
:|
9:10 a.m.
On Tue, Sep 30, 2008 at 05:57:20PM +0400, Anton Protopopov wrote:
>
> Possibly, though its not terribly consistent so far.
>
> Xen - vifNNN.MMM (NNN dom ID, MMM = nic number)
> QEMU - vnetNNN (NNN = global host nic number)
> LXC - vethNNN (MMM = global host nic number)
And how these drivers choose NNN? Do QEMU driver and LXC driver use the same
NNN?
Start from vnet0 and look for the first available name.
>
> We can't change the format Xen uses, but it could be desirable to make
> LXC, QEMU and OpenVZ all use vnetNNN scheme by default for auto assigned
> nics names on the host side.
Now openvz driver chooses not interface name in host, but interface name in
container.
The interface name inside the container is not something that is expressed
in the libvirt XML. That is left upto the guest OS to decide, and not
something libvirt needs to care about.
We only care about configuration from the host side.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
1:33 a.m.
2008/9/30 Daniel P. Berrange <berrange(a)redhat.com>
On Tue, Sep 30, 2008 at 05:57:20PM +0400, Anton Protopopov wrote:
> >
> > Possibly, though its not terribly consistent so far.
> >
> > Xen - vifNNN.MMM (NNN dom ID, MMM = nic number)
> > QEMU - vnetNNN (NNN = global host nic number)
> > LXC - vethNNN (MMM = global host nic number)
>
>
> And how these drivers choose NNN? Do QEMU driver and LXC driver use the
same
> NNN?
Start from vnet0 and look for the first available name.
> >
> > We can't change the format Xen uses, but it could be desirable to make
> > LXC, QEMU and OpenVZ all use vnetNNN scheme by default for auto
assigned
> > nics names on the host side.
>
>
> Now openvz driver chooses not interface name in host, but interface name
in
> container.
The interface name inside the container is not something that is expressed
in the libvirt XML. That is left upto the guest OS to decide, and not
something libvirt needs to care about.
In OpenVZ case you _must_ to decide what name the
interface will have inside the container. The command line for ading an
interface in OpenVZ looks like
# vzctl set $veid --ifname_add ifname[mac, host_ifname, host_mac]
The only mandatory field is the name of _container interface_
The possible solution is the following:
* absolutely ignore the <target dev=".."> in openvz XML description
* Set (ifname, host_ifname) of the interface to (eth${N}, veth${ID}.${N}),
where ID is the container id and N is the interface number within that
container.
It is simplifies saving the bridge name and adding the interface to the
bridge too,
for example, by adding the following line to the $veid.conf:
#BRIDGE$N: <name of bridge for interface # $N >
We only care about configuration from the host side.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/:|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org:|
|: http://autobuild.org -o-
http://search.cpan.org/~danberr/<http://search.cpan.org/%7Edanberr/>:|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
:|
4:13 a.m.
On Wed, Oct 01, 2008 at 10:33:49AM +0400, Anton Protopopov wrote:
2008/9/30 Daniel P. Berrange <berrange(a)redhat.com>
> On Tue, Sep 30, 2008 at 05:57:20PM +0400, Anton Protopopov wrote:
> >
> > Now openvz driver chooses not interface name in host, but interface name
> in
> > container.
>
> The interface name inside the container is not something that is expressed
> in the libvirt XML. That is left upto the guest OS to decide, and not
> something libvirt needs to care about.
In OpenVZ case you _must_ to decide what name the
interface will have inside the container. The command line for ading an
interface in OpenVZ looks like
# vzctl set $veid --ifname_add ifname[mac, host_ifname, host_mac]
The only mandatory field is the name of _container interface_
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.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
9:08 a.m.
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
9:24 a.m.
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 :)
2:31 a.m.
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.
5:43 a.m.
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?
+ 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...
Other looks good.
6:09 a.m.
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?
7:04 a.m.
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?
I think we can simplify format to simplify
parsing.
#BRIDGE="virbr1:veth101.0,veth101.1,veth101.2"
In this case we may use
openvzReadConfigParam(101, "#BRIDGE", value, 1024)
7:14 a.m.
On Fri, Oct 03, 2008 at 04:04:06PM +0400, Evgeniy Sokolov wrote:
>
>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?
I think we can simplify format to simplify parsing.
#BRIDGE="virbr1:veth101.0,veth101.1,veth101.2"
There's no need to store veth101.0, veth101.2 - they are automatically
generated & not intended to be stable across restarts. It is merely
neccessary to persist the name of the bridge (or virtual network) to
which they are attached, and the MAC address.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
8:33 a.m.
2008/10/3 Daniel P. Berrange <berrange(a)redhat.com>
On Fri, Oct 03, 2008 at 04:04:06PM +0400, Evgeniy Sokolov wrote:
> >
> >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?
> I think we can simplify format to simplify parsing.
> #BRIDGE="virbr1:veth101.0,veth101.1,veth101.2"
I do not undesrtand how it will simplify parsing: the iterator
in parsing is an interface name, not bridge name. I attached a patch, so
you will see how I do think about it :) (this patch includes all
discussed changes)
There's no need to store veth101.0, veth101.2 - they are automatically
generated & not intended to be stable across restarts. It is merely
No, there is. They are generated only once --- when VE container is created.
After that they are stored in the config file.
neccessary to persist the name of the bridge (or virtual network) to
which they are attached, and the MAC address.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/:|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org:|
|: http://autobuild.org -o-
http://search.cpan.org/~danberr/<http://search.cpan.org/%7Edanberr/>:|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
:|
10:47 a.m.
2008/10/3 Daniel P. Berrange <berrange(a)redhat.com
<mailto:berrange@redhat.com>>
On Fri, Oct 03, 2008 at 04:04:06PM +0400, Evgeniy Sokolov wrote:
> >
> >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?
> I think we can simplify format to simplify parsing.
> #BRIDGE="virbr1:veth101.0,veth101.1,veth101.2"
I do not undesrtand how it will simplify parsing: the iterator
in parsing is an interface name, not bridge name. I attached a patch, so
you will see how I do think about it :) (this patch includes all
discussed changes)
My point of view is to use small count common methods to
manipulate
config parameters. That is don't use array of differend methods for
different types of data. In current case we can transform format to be
used common functions.
For example:
if we will use format
#BRIDGE-ifname=<>
we can drop openvzGetDefinedBridge and use one existing method
openvzReadConfigParam(veid, "#BRIDGE-ifname", value, sizeof(value));
openvzSetDefinedBridge can be simplified if create
openvzAppendParamToConfig
openvzSetDefinedBridge() {
openvzReadConfigParam()
if not found
openvzAppendParamToConfig()
return
}
May be you will found better way.
4:02 a.m.
I do not undesrtand how it will simplify parsing: the iterator
> in parsing is an interface name, not bridge name. I attached a patch, so
> you will see how I do think about it :) (this patch includes all
> discussed changes)
>
My point of view is to use small count common methods to manipulate config
parameters. That is don't use array of differend methods for different types
of data. In current case we can transform format to be used common
functions.
For example:
if we will use format
#BRIDGE-ifname=<>
we can drop openvzGetDefinedBridge and use one existing method
openvzReadConfigParam(veid, "#BRIDGE-ifname", value, sizeof(value));
openvzSetDefinedBridge can be simplified if create
openvzAppendParamToConfig
openvzSetDefinedBridge() {
openvzReadConfigParam()
if not found
openvzAppendParamToConfig()
return
}
I done the following:
- Add function openvzAppendConfigParam(veid, param, value)
This function simply appends a string `param="value"` to config file.
- Rewrite functions openvz{Get,Set}DefinedBridge to use that function
I think, we need to rewrite {Get,Set}UUID functions in the same manner.
+ case VIR_DOMAIN_NET_TYPE_BRIDGE:
+ veth = net->ifname;
+ bridge = net->data.bridge.brname;
+ if (rc = brAddInterface(brctl, bridge, veth)) {
+ openvzError(conn, VIR_ERR_INTERNAL_ERROR,
+ _("failed to add %s device to %s: %s"),
+ veth, bridge, strerror(rc));
+ goto exit;
+ }
+ break;
It will be good to check veth & bridge for NULL. Potentially it may happens
when config is broken.
Done. If veth or bridge is NULL, then openvzError is raised
and one iteration of loop is passed.
@@ -602,6 +713,12 @@ openvzDomainCreate(virDomainPtr dom)
return -1;
}
+ if (openvzSetBridges(dom->conn, vm->def->name, vm->def->nets) < 0)
{
+ openvzError(dom->conn, VIR_ERR_INTERNAL_ERROR,
+ _("Could not configure bridges"));
+ return -1;
+ }
+
Also, we need to set bridges in openvzDomainReboot method.
Done.
+ 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...
Write function openvzGenerateContainerVethName.
When called, it will search for interface names in $veid.conf.
If there are ethN,...,ethM, it will return name "ethL",
where L = 1+max(N,...,M)
9:01 a.m.
I done the following:
- Add function openvzAppendConfigParam(veid, param, value)
This function simply appends a string `param="value"` to config file.
- Rewrite functions openvz{Get,Set}DefinedBridge to use that function
Patch looks good now.
I think, we need to rewrite {Get,Set}UUID functions in the same
manner.
Yes, good idea.
3:29 a.m.
Hi all,
2008/10/8 Evgeniy Sokolov <evg(a)openvz.org>
> I done the following:
> - Add function openvzAppendConfigParam(veid, param, value)
> This function simply appends a string `param="value"` to config file.
> - Rewrite functions openvz{Get,Set}DefinedBridge to use that function
>
> Patch looks good now.
So, what about that patch? Will it be commited or there are reasons against
it?
(Or maybe nobody has seen it yet? :))
10:06 a.m.
On Wed, Oct 08, 2008 at 01:02:44PM +0400, Anton Protopopov wrote:
>
> I do not undesrtand how it will simplify parsing: the iterator
>> in parsing is an interface name, not bridge name. I attached a patch, so
>> you will see how I do think about it :) (this patch includes all
>> discussed changes)
>>
> My point of view is to use small count common methods to manipulate config
> parameters. That is don't use array of differend methods for different types
> of data. In current case we can transform format to be used common
> functions.
>
> For example:
> if we will use format
> #BRIDGE-ifname=<>
> we can drop openvzGetDefinedBridge and use one existing method
> openvzReadConfigParam(veid, "#BRIDGE-ifname", value, sizeof(value));
This idea is not good - if someone starts the container outside of libvirt
using 'vzctl start 101', then the bridge config will not be activated.
The latest openvz code has explicit support in its configuration file
for setting the bridge device name, via a 'bridge=br0' attribute in
the NETIF= config setting. This can also be specified wehn invoking
the vzctl --netif_add command:
http://wiki.openvz.org/Virtual_Ethernet_device#Making_a_bridged_veth-devi...
So, if using openvz > 3.0.22, we should use this config param to record
the bridge and not invent our own.
To make upgrades easy, we should also use this config syntax for version
of openvz <= 3.0.22, and simply document that they need to create a helper
script /usr/sbin/vznetaddbr to make it work - they can even just grab
the helper script straight from newer openvz code. eg
http://git.openvz.org/?p=vzctl;a=blob;f=bin/vznetaddbr.in;h=81975b3275c7e...
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
11:41 a.m.
2008/10/14 Daniel P. Berrange <berrange(a)redhat.com>
On Wed, Oct 08, 2008 at 01:02:44PM +0400, Anton Protopopov wrote:
> >
> > I do not undesrtand how it will simplify parsing: the iterator
> >> in parsing is an interface name, not bridge name. I attached a patch,
so
> >> you will see how I do think about it :) (this patch includes all
> >> discussed changes)
> >>
> > My point of view is to use small count common methods to manipulate
config
> > parameters. That is don't use array of differend methods for different
types
> > of data. In current case we can transform format to be used common
> > functions.
> >
> > For example:
> > if we will use format
> > #BRIDGE-ifname=<>
> > we can drop openvzGetDefinedBridge and use one existing method
> > openvzReadConfigParam(veid, "#BRIDGE-ifname", value, sizeof(value));
This idea is not good - if someone starts the container outside of libvirt
using 'vzctl start 101', then the bridge config will not be activated.
The latest openvz code has explicit support in its configuration file
for setting the bridge device name, via a 'bridge=br0' attribute in
the NETIF= config setting. This can also be specified wehn invoking
the vzctl --netif_add command:
http://wiki.openvz.org/Virtual_Ethernet_device#Making_a_bridged_veth-devi...
So, if using openvz > 3.0.22, we should use this config param to record
the bridge and not invent our own.
OK, I will try to implement this in libvirt
To make upgrades easy, we should also use this config syntax for version
of openvz <= 3.0.22, and simply document that they need to create a helper
script /usr/sbin/vznetaddbr to make it work - they can even just grab
the helper script straight from newer openvz code. eg
http://git.openvz.org/?p=vzctl;a=blob;f=bin/vznetaddbr.in;h=81975b3275c7e...
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/:|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org:|
|: http://autobuild.org -o-
http://search.cpan.org/~danberr/<http://search.cpan.org/%7Edanberr/>:|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
:|
11:57 a.m.
2008/10/14 Anton Protopopov <aspsk2(a)gmail.com>
2008/10/14 Daniel P. Berrange <berrange(a)redhat.com>
> On Wed, Oct 08, 2008 at 01:02:44PM +0400, Anton Protopopov wrote:
> > >
> > > I do not undesrtand how it will simplify parsing: the iterator
> > >> in parsing is an interface name, not bridge name. I attached a patch,
> so
> > >> you will see how I do think about it :) (this patch includes all
> > >> discussed changes)
> > >>
> > > My point of view is to use small count common methods to manipulate
> config
> > > parameters. That is don't use array of differend methods for different
> types
> > > of data. In current case we can transform format to be used common
> > > functions.
> > >
> > > For example:
> > > if we will use format
> > > #BRIDGE-ifname=<>
> > > we can drop openvzGetDefinedBridge and use one existing method
> > > openvzReadConfigParam(veid, "#BRIDGE-ifname", value,
sizeof(value));
>
> This idea is not good - if someone starts the container outside of libvirt
> using 'vzctl start 101', then the bridge config will not be activated.
>
> The latest openvz code has explicit support in its configuration file
> for setting the bridge device name, via a 'bridge=br0' attribute in
> the NETIF= config setting. This can also be specified wehn invoking
> the vzctl --netif_add command:
>
>
>
http://wiki.openvz.org/Virtual_Ethernet_device#Making_a_bridged_veth-devi...
>
> So, if using openvz > 3.0.22, we should use this config param to record
> the bridge and not invent our own.
OK, I will try to implement this in libvirt
Oops, someone already did it.. :)
>
>
> To make upgrades easy, we should also use this config syntax for version
> of openvz <= 3.0.22, and simply document that they need to create a helper
> script /usr/sbin/vznetaddbr to make it work - they can even just grab
> the helper script straight from newer openvz code. eg
>
>
>
http://git.openvz.org/?p=vzctl;a=blob;f=bin/vznetaddbr.in;h=81975b3275c7e...
>
> Daniel
> --
> |: Red Hat, Engineering, London -o-
> http://people.redhat.com/berrange/ :|
> |: http://libvirt.org -o- http://virt-manager.org -o-
> http://ovirt.org :|
> |: http://autobuild.org -o-
> http://search.cpan.org/~danberr/ <http://search.cpan.org/%7Edanberr/> :|
> |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
> :|
>
5916
days inactive
5931
days old
24 comments
4 participants
participants (4)
-
Anton Protopopov -
Daniel P. Berrange -
Evgeniy Sokolov -
Evgeniy V. Sokolov