Custom interface names with <interface type='ethernet'> does not start qemu

Bug #1574957 reported by Matt Mullins
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Starting up a VM with the following <interface> definition fails in libvirt 1.3.1-1ubuntu10 with "error: Unable to get index for interface vm28_0: No such device":
    <interface type='ethernet'>
      <mac address='00:16:3e:2a:91:38'/>
      <script path='no'/>
      <target dev='vm28_0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

If I remove the <target> definition, the VM starts, but with the interface named tap0.

The above interface definition does work on trusty, and it also works on a locally-built package with libvirt 1.3.3.

Tags: patch
Revision history for this message
Matt Mullins (mokomull) wrote :

I have verified that 4bbe1029f2fb6cd1c102794951a944c62fdbd0e6 "qemu: fix ifindex array reported to systemd" introduced this bug since it added a call to virNetDevGetIndex for all VIR_DOMAIN_NET_TYPE_ETHERNET devices with a known name, even if the device hasn't been created yet. I believe 9c17d665fdc5f0ab74500a14c30627014c11b2c0 "autocreate tap device for ethernet network type" fixes it by creating the tap device in the libvirt process. This commit is included in 1.3.3.

It can be worked-around by calling tunctl outside of libvirt, but it would be cleaner to have libvirt manage the lifetime of the device (by way of holding the /dev/net/tun fd). What needs to happen to get this change included?

Revision history for this message
Matt Mullins (mokomull) wrote :

I have backported 9c17d665fdc5f0ab74500a14c30627014c11b2c0 to v1.3.1 and verified that it does fix the issue. That backport is attached, though some functions were moved between v1.3.1 and v1.3.3 -- I don't know if it would be preferable to carry the backport or to move Ubuntu forward to 1.3.3 or later.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Backport of 9c17d665 to v1.3.1" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
tags: added: server-next
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Matt,
I looked into this and had to realize that I missed your bug.
I beg your pardon - I took over looking after qemu/libvirt a while ago and this is an issue from the time this was not clear yet and we seemed to have missed it for way too much time.

Especially since you made all the great effort to even test, bisect and backport a fix.
I really beg your pardon!

OTOH (the good side of things) the issue you are referring to is already fixed in bug 1620407.
We came to the same conclusion there as you did, we did look into backporting but for the complexities you have found as well looked into alternatives.
It turned out we needed way less to get it working.

So since libvirt (1.3.1-1ubuntu10.8) your issue should be fixed.
If not for your specific kind of setup please report here, I'm subscribed now and it should not be another year almsot :-/

tags: removed: server-next
Changed in libvirt (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.