Bug 965783 - duplicate NIC interface is created for the guest vm while no vnet interface is created on the host system
duplicate NIC interface is created for the guest vm while no vnet interface i...
Status: CLOSED WONTFIX
Product: Virtualization Tools
Classification: Community
Component: virt-manager (Show other bugs)
unspecified
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Cole Robinson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-21 13:38 EDT by Ivan Lezhnjov IV
Modified: 2013-05-21 15:35 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-21 15:35:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ivan Lezhnjov IV 2013-05-21 13:38:27 EDT
Description of problem:

Adding/hot-plugging a new virtio NIC for Ubuntu guest (Ubuntu 10.04.4 LTS, linux-image-2.6.32-40-server), with acpiphp module loaded, using a shared device name as 'br1' bridge interface results in two things:

- the new interface gets created in the guest vm, it even gets automatically brought up and configured (provided /etc/network/interfaces has been set up 
- however, the corresponding vnet interface never is created on the host system, neither is bridge configuration updated
- thus, the bridging doesn't work
- i.e. unless the guest vm is powered down (not rebooted, reboot is not enough)
- then in virt-manager a duplicate of the new virtio NIC appears (which can/should be deleted) and after that everything works as expected: vnet interface is created on the host, bridge configuration is updated.

Version-Release number of selected component (if applicable):

virt-manager 0.9.1-1ubuntu5
libvirt packages at version 0.9.8-2ubuntu17.8

How reproducible:

Seems to be 100% reproducible. 

I have reproduced this twice, with the same host machine and two different guest VMs (both running the same Ubuntu version but slightly different kernel versions)


Steps to Reproduce:
1. Log into guest
2. modprobe acpiphp
3. prepare /etc/network/interfaces and add configuration for the new interface eth1 (or whatever yours will be)
4. start virt-manager and add new virtio NIC specifying Source device as a shared device of bridge type with name 'br1'
5. apply change in virt-manager
6. eth1 should appear in the guest vm, it should be brought up configured with IP address information, link status set to up on eth1
7. on the host machine vnet shouldn't have appeared, bridge configuration haven't been updated either
8. close virt-manager
9. power down (I used 'sudo halt') the guest vm
10. start virt-manager again
11. open settings for the guest vm in question
12. you should see a duplicate NIC device for the mos recent created one that you're having trouble with
13. remove that NIC which is the lowest on the list in the left side pane
14. apply changes
15. start up the vm (I would just press green 'Power on the virtual machine' button that resembles Play button in an audio player)
16. vnet interface should have been created on the host machine, bridge configuration should have been updated also

Actual results:

vnet interface is not created on the host system
bridge configuration is not updated
traffic originating from a guest is not relayed via the bridging interface
duplicate NIC device is created and can be discovered only after a complete power off of a guest vm in question

Expected results:

vnet interface should be created and bridging configuration should be updated immediately
traffic originating from a guest should be relayed via the bridging interface
not duplicate NIC devices must be created

Additional info:

I've tried to search for a similar report, and I realize I'm running an older version of virt-manager but I haven't found a report similar to this and I thought I'd make sure you know about it.
Comment 1 Cole Robinson 2013-05-21 15:35:10 EDT
I haven't heard of this before. But yes, your version of virt-manager is 1.5 years old, and the actual culprit is likely libvirt or qemu, and those versions are undoubtedly quite old as well.

Your options are:

1) File the bug with your distro and hope that they fix it.

2) Try to reproduce with newer virt-manager. If you reproduce, add in newer libvirt. Then add newer qemu. If you can reproduce with a modern environment then devs have something to work with, but until then I don't think any upstream developer is going to do anything.

Closing as WONTFIX, but if you reproduce with modern bits feel free to reopen.

Note You need to log in before you can comment on or make changes to this bug.