[libvirt] Overriding vnetN with the <target> element in xml configuration not working
Hello, I've been trying to dedicated a vnet interface to each virtual machine in order to be able to monitor their traffic, looking at http://libvirt.org/formatdomain.html#elementsNICSBridge it says that a virtual machine could have a specific vnetN specified in the xml element <target>, like <target dev='vnet7'/> . Unfortunately its not working and still it comes with vnet(current+1), here's my configuration for a qemu-kvm guest. <interface type='bridge'> <source bridge='virbr0'/> <target dev='vnet7'/> <mac address='00:16:3e:6c:1f:9d'/> </interface> I'm running on F9 x86_64, libvirt-0.4.4-2.fc9.x86_64 libvirt-python-0.4.4-2.fc9.x86_64 kvm-65-7.fc9.x86_64 qemu-0.9.1-6.fc9.x86_64 I haven't yet tested this with a RHEL box to know if it is version specific issue to open a bugzilla report, any input is appreciated. /* || Thanks, Ahmed Medhat || ultimatetux [at] gmail [dot] com || +2-012-4184768 || In a world without walls and fences, who needs Windows and Gates? */
Ok, so its kinda creepy now, it works with change the device name to anything but vnetN. This is what did work with me.. <interface type='bridge'> <source bridge='virbr0'/> <target dev="vn01"/> <mac address='00:16:3e:6c:1f:9d'/> </interface> This must be something with libvirtd code handling this specific element directive. I will wait for someone to do any input for a while then fire up a bug report. /* || Thanks, Ahmed Medhat || ultimatetux [at] gmail [dot] com || +2-012-4184768 || In a world without walls and fences, who needs Windows and Gates? */ On Sat, Sep 27, 2008 at 2:32 AM, Ahmed Medhat <ultimatetux@gmail.com> wrote:
Hello,
I've been trying to dedicated a vnet interface to each virtual machine in order to be able to monitor their traffic, looking at http://libvirt.org/formatdomain.html#elementsNICSBridge it says that a virtual machine could have a specific vnetN specified in the xml element <target>, like <target dev='vnet7'/> .
Unfortunately its not working and still it comes with vnet(current+1), here's my configuration for a qemu-kvm guest.
<interface type='bridge'> <source bridge='virbr0'/> <target dev='vnet7'/> <mac address='00:16:3e:6c:1f:9d'/> </interface>
I'm running on F9 x86_64,
libvirt-0.4.4-2.fc9.x86_64 libvirt-python-0.4.4-2.fc9.x86_64 kvm-65-7.fc9.x86_64 qemu-0.9.1-6.fc9.x86_64
I haven't yet tested this with a RHEL box to know if it is version specific issue to open a bugzilla report, any input is appreciated.
/* || Thanks, Ahmed Medhat || ultimatetux [at] gmail [dot] com || +2-012-4184768 || In a world without walls and fences, who needs Windows and Gates? */
On Sat, Sep 27, 2008 at 02:58:14AM +0200, Ahmed Medhat wrote:
Ok, so its kinda creepy now, it works with change the device name to anything but vnetN.
vnetNNN is an automatically generated device name pattern. We explicitly ignore any requested target dev with that naming pattern because manually specified name will almost certainly clash with an auto-generated one and cause the domain to fail to start. The same applies for 'vifNNNN' naming
This is what did work with me..
<interface type='bridge'> <source bridge='virbr0'/> <target dev="vn01"/> <mac address='00:16:3e:6c:1f:9d'/> </interface>
This must be something with libvirtd code handling this specific element directive.
I will wait for someone to do any input for a while then fire up a bug report.
It isn't a bug - it is delibrate. 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 :|
Well, I don't recall reading this constrain anywhere in the documentation ! /* || Thanks, Ahmed Medhat || ultimatetux [at] gmail [dot] com || +2-012-4184768 || Impossible is not a fact, It's an opinion! */ On Mon, Sep 29, 2008 at 11:30 AM, Daniel P. Berrange <berrange@redhat.com> wrote:
On Sat, Sep 27, 2008 at 02:58:14AM +0200, Ahmed Medhat wrote:
Ok, so its kinda creepy now, it works with change the device name to anything but vnetN.
vnetNNN is an automatically generated device name pattern. We explicitly ignore any requested target dev with that naming pattern because manually specified name will almost certainly clash with an auto-generated one and cause the domain to fail to start.
The same applies for 'vifNNNN' naming
This is what did work with me..
<interface type='bridge'> <source bridge='virbr0'/> <target dev="vn01"/> <mac address='00:16:3e:6c:1f:9d'/> </interface>
This must be something with libvirtd code handling this specific element directive.
I will wait for someone to do any input for a while then fire up a bug report.
It isn't a bug - it is delibrate.
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 :|
On Wed, Oct 01, 2008 at 08:45:53PM +0200, Ahmed Medhat wrote:
Well,
I don't recall reading this constrain anywhere in the documentation !
Documentation is never perfect and always a moving target. If anyone has improvements they want to make to the docs, all the website HTML is in the CVS repo under the docs/ directory & patches are welcomed. The domain XML format is documented in the docs/formatdomain.html.in file. Regards, 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 :|
participants (2)
-
Ahmed Medhat -
Daniel P. Berrange