[libvirt] invoking interface.script - missing interface name of domain

Hi, i would like to write a small script - bringing up my qemu-kvm interface and - connecting it to a bridge using the following XML domain-syntax : .... <interface type='ethernet'> <script path='/etc/kvm/qemu-ifup'/> </interface> .... The script will invoked (from qemu-kvm I thinkg) but I can't find any arguments like "interface name" - so my script cannot setup the bridge correctly because of missing information about the interface name. At the moment, I look to the PPID (parent pid of the script) and parse the qemu commandline (ps ef) to find out the interfacename - but it's only a workaround. Q: Is there a way to get informed about the interface libvirt/quemu used for the new domain ? regards Danny

On Tue, Jan 20, 2009 at 04:12:06PM +0100, Daniel Schwager wrote:
Hi,
i would like to write a small script - bringing up my qemu-kvm interface and - connecting it to a bridge using the following XML domain-syntax :
.... <interface type='ethernet'> <script path='/etc/kvm/qemu-ifup'/> </interface> ....
The script will invoked (from qemu-kvm I thinkg) but I can't find any arguments like "interface name" - so my script cannot setup the bridge correctly because of missing information about the interface name.
At the moment, I look to the PPID (parent pid of the script) and parse the qemu commandline (ps ef) to find out the interfacename - but it's only a workaround.
Q: Is there a way to get informed about the interface libvirt/quemu used for the new domain ?
QEMU is responsible for passing arguments to the interface scripts, so its out of libvirt's control. QEMU passes a single paramter to the script, which is the name of the TAP device interface being added. If you don't give a <target dev='tap3'> libvirt generates a TAP device name vnetXXXX. 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 :|

Hi Daniel, thx for the fast answer.
QEMU is responsible for passing arguments to the interface scripts, so its out of libvirt's control. QEMU passes a single paramter to the script, which is the name of the TAP device interface being added. If you don't give a <target dev='tap3'> libvirt generates a TAP device name vnetXXXX.
If I do not specify the <target>-element inside of <interface>, your docu told me "The guest will have a tun device created with a name of vnetN, which can also be overridden with the <target> element." (http://www.libvirt.org/formatdomain.html#elementsNICS) I understood this in the following way: I can remove the target-element and I will get automatically a target name "vnet<N>" - if I do this, I will get an interfacename "(null") : 5459 ? Sl 0:01 /usr/bin/kvm -S -M pc -m 500 -smp 1 -name solidcam -uuid 60a8db24-86a5-f9fc-16ee-b60b32411dd8 -monitor pty -boot c -drive file=/srv/winxp127-xxx.dsk,if=ide,index=0,boot=on -net nic,macaddr=52:54:00:46:58:41,vlan=0 -net tap,ifname=(null),script=/etc/kvm/qemu-ifup,vlan=0 -serial pty -parallel none -usb -usbdevice tablet -vnc 0.0.0.0:0 So, this means libvirt is NOT responsible for the naming auf the target. Maybe you have to clarify this in the docu. For my case, I have to write a domain-xml dynamically and specify the interface name (target-element) to the domain-xml like <interface type='ethernet'> <script path='/etc/kvm/qemu-ifup'/> <target dev='my-new-name001122'/> </interface> regards Danny

On Tue, Jan 20, 2009 at 04:44:22PM +0100, Daniel Schwager wrote:
Hi Daniel,
thx for the fast answer.
QEMU is responsible for passing arguments to the interface scripts, so its out of libvirt's control. QEMU passes a single paramter to the script, which is the name of the TAP device interface being added. If you don't give a <target dev='tap3'> libvirt generates a TAP device name vnetXXXX.
If I do not specify the <target>-element inside of <interface>, your docu told me
"The guest will have a tun device created with a name of vnetN, which can also be overridden with the <target> element." (http://www.libvirt.org/formatdomain.html#elementsNICS)
I understood this in the following way: I can remove the target-element and I will get automatically a target name "vnet<N>" - if I do this, I will get an interfacename "(null") :
5459 ? Sl 0:01 /usr/bin/kvm -S -M pc -m 500 -smp 1 -name solidcam -uuid 60a8db24-86a5-f9fc-16ee-b60b32411dd8 -monitor pty -boot c -drive file=/srv/winxp127-xxx.dsk,if=ide,index=0,boot=on -net nic,macaddr=52:54:00:46:58:41,vlan=0 -net tap,ifname=(null),script=/etc/kvm/qemu-ifup,vlan=0 -serial pty -parallel none -usb -usbdevice tablet -vnc 0.0.0.0:0
That is a bug I'm afraid - it *should* pass the real auto-generated interface name but for some reason it isn't. I see this is one of the XML configs we don't have tested in our xml -> ARGV conversion test.
So, this means libvirt is NOT responsible for the naming auf the target. Maybe you have to clarify this in the docu.
For my case, I have to write a domain-xml dynamically and specify the interface name (target-element) to the domain-xml like
<interface type='ethernet'> <script path='/etc/kvm/qemu-ifup'/> <target dev='my-new-name001122'/> </interface>
Yes, explicitly giving a interface name is a reasonable workaround until i fix the bug. 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 Tue, Jan 20, 2009 at 04:44:22PM +0100, Daniel Schwager wrote:
QEMU is responsible for passing arguments to the interface
Hi Daniel, within the latest CVS checkout, the problem below is not fixed. It there an open bug (to track) in redhat bugzilla for it ? If not, should I create one ? regards Danny scripts,
so its out of libvirt's control. QEMU passes a single paramter to the script, which is the name of the TAP device interface being added. If you don't give a <target dev='tap3'> libvirt generates a TAP device name vnetXXXX.
If I do not specify the <target>-element inside of <interface>, your docu told me
"The guest will have a tun device created with a name of vnetN, which can also be overridden with the <target> element." (http://www.libvirt.org/formatdomain.html#elementsNICS)
That is a bug I'm afraid - it *should* pass the real auto-generated interface name but for some reason it isn't. I see this is one of the XML configs we don't have tested in our xml -> ARGV conversion test.
...
Daniel
participants (2)
-
Daniel P. Berrange
-
Daniel Schwager