9:12 a.m.
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
9:19 a.m.
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 :|
9:44 a.m.
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
9:51 a.m.
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 :|
3:57 a.m.
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
On Tue, Jan 20, 2009 at 04:44:22PM +0100, Daniel Schwager wrote:
> > 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)
>
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
5811
days inactive
5821
days old
4 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Daniel Schwager