DescriptionGiuseppe Scrivano
2014-01-29 15:04:23 UTC
+++ This bug was initially created as a clone of Bug #846255 +++
Description of problem:
virt-manager add macvtap device , even choose "NO" in the GUI option
Version-Release number of selected component (if applicable):
libvirt-0.10.0-0rc0.el6.x86_64
virt-manager-0.9.0-14.el6.x86_64
How reproducible:
100%
Steps to Reproduce:
1. start a domain
2. run virt-manager => Add Hardware => Network => choose Host device eth0:macvtap => Finish
pop up warning message:
"Are you sure want to add this device"
"This device could not be attached to the running machine. Would you like to make the device available after the next guest shutdown?"
NO or YES
3. choose NO
4. check the host net device
5.# ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:23:ae:8f:f2:b3 brd ff:ff:ff:ff:ff:ff
inet 10.66.82.251/23 brd 10.66.83.255 scope global eth0
inet6 fe80::223:aeff:fe8f:f2b3/64 scope link
valid_lft forever preferred_lft forever
3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 52:54:00:ed:7d:b4 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
link/ether 52:54:00:ed:7d:b4 brd ff:ff:ff:ff:ff:ff
133: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
link/ether 52:54:00:54:61:42 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe54:6142/64 scope link
valid_lft forever preferred_lft forever
Actual results:
macvtap device always add
Expected results:
choose NO do not add the device
Additional info:
1.I found the macvtap device will create once you click "Finish" , actually device has created before you choose Yes or No.
--- Additional comment from RHEL Product and Program Management on 2012-08-07 05:32:47 EDT ---
Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
--- Additional comment from Ludek Smid on 2013-03-07 10:25:34 EST ---
Since the release flag was set to ? after the qa_ack and pm_ack flags were set to + (was likely set for the previous release), the qa_ack and pm_ack flags have been reset to ? by the bugbot (pm-rhel). This action ensures the proper review by Product Management.
--- Additional comment from John Skeoch on 2013-10-20 17:47:20 EDT ---
User whuang's account has been closed
Can you show the --debug output from the error?
virt-manager tries to hotplug the device, my guess is libvirt gets part way through the macvtap process, fails, returns error, but isn't cleaning up correctly. So this is likely a libvirt bug
Comment 2Giuseppe Scrivano
2014-01-30 12:05:10 UTC
I am not able to reproduce this anymore on my Fedora 20, it was probably a problem in my testing environment. I will reopen if I hit this again.