Bug 1123065 - KVM guests cannot successfully connect via macvtap with iwlwifi interfaces(?)
Summary: KVM guests cannot successfully connect via macvtap with iwlwifi interfaces(?)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-24 18:35 UTC by Adam Williamson
Modified: 2015-11-03 00:23 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-03 00:22:22 UTC


Attachments (Terms of Use)

Description Adam Williamson 2014-07-24 18:35:24 UTC
I tried using macvtap-based bridging for KVM virtual guests on my laptops, to see if it would work, but it doesn't seem to, not on either one. One is running current F21, the other current F20 with updates-testing.

One (xps13) has:

01:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6235 [8086:088e] (rev 24)

that's the one running current F21, with kernel 3.16.0-0.rc6.git1.2.fc22 (I think from rawhide-nodebug).

the other (vaioz) has:

02:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6200 [8086:422c] (rev 35)

that's the one running current F20, with kernel 3.15.6-200.fc20.

in both cases I just set the NIC for a guest to "Host device wlpXs0 : macvtap" (the wireless adapter) in virt-manager, with "Source mode:" set to the default ("Bridge"). Then I tried booting the guest (using a Fedora 20 live image, and also in the vaioz case using the EFI shell).

In both cases, on the host the 'macvtap0' device is created when the VM starts up and I see a /dev/tapX , but the guest could not manage to get an IP address from the router via DHCP.

In both cases, I noticed the 'wlpXs0' device on the host was not set to PROMISC mode (which apparently libvirt should cause to happen?) However, rebooting (to get a clean start), setting the device to PROMISC mode manually with ifconfig, and *then* booting the VM didn't help; it still didn't work.

Additionally, *only* on the 'xps13' box, it seems macvtap0 can only be created once per boot. The first time I start the guest VM after boot, macvtap0 is created correctly as described above...but if I shut it down (at which point macvtap0 is destroyed) and then start it up again, macvtap0 isn't created, and I see these errors in the logs:

Jul 24 11:32:48 xps13.happyassassin.net NetworkManager[4808]: <info> Activation (macvtap0) Stage 3 of 5 (IP Configure Start) started...
Jul 24 11:32:48 xps13.happyassassin.net NetworkManager[4808]: <info> (macvtap0): device state change: config -> ip-config (reason 'none') [50 70 0]
Jul 24 11:32:48 xps13.happyassassin.net NetworkManager[4808]: <info> (macvtap0): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]
Jul 24 11:32:48 xps13.happyassassin.net NetworkManager[4808]: <warn> Activation (macvtap0) failed for connection 'macvtap0'
Jul 24 11:32:48 xps13.happyassassin.net NetworkManager[4808]: <info> Activation (macvtap0) Stage 3 of 5 (IP Configure Start) complete.
Jul 24 11:32:48 xps13.happyassassin.net NetworkManager[4808]: <info> (macvtap0): device state change: failed -> disconnected (reason 'none') [120 30 0]
Jul 24 11:32:48 xps13.happyassassin.net NetworkManager[4808]: <info> (macvtap0): deactivating device (reason 'none') [0]

Aside from that issue with second creation of macvtap0 on xps13 (again, that bug doesn't happen on vaioz), I don't see anything terribly useful in the logs on either host or guest; the host log shows the macvtap0 device being created and coming up, the guest log show DHCP attempts that time out, and that's kinda it. I don't know how to get more useful debugging output, please do advise. Thanks!

Comment 1 Rino Rondan 2014-11-26 00:44:21 UTC
I have same situation, when i create a vm and then put inteface wlan to use macvtap dhclient never get any ip (in mode bridge with direct). BUt with wired interface dhclient works fine (same bridge and direct)

Comment 2 Laine Stump 2014-11-26 02:49:15 UTC
Unless the wireless access point has special software to deal with it, I would be skeptical of this ever working - it's the same problem as trying to attach a wireless interface to a host bridge - the AP expects there to be only a single MAC address at the other end of any association. Macvtap is after all just a variation on an L2 bridge.

Comment 3 Justin M. Forbes 2015-01-27 14:58:42 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs.

Fedora 21 has now been rebased to 3.18.3-201.fc21.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 4 Fedora Kernel Team 2015-04-28 18:29:06 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs.

Fedora 21 has now been rebased to 3.19.5-200.fc21.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22.

If you experience different issues, please open a new bug report for those.

Comment 5 Itamar Reis Peixoto 2015-11-02 22:28:11 UTC
create a vm setup macvtap with wireless card.

Comment 6 Adam Williamson 2015-11-02 22:44:03 UTC
I wouldn't mind if this is just closed NOTABUG per #c2, it sounds like this isn't really expected to work on wifi, but I don't think I can say that authoritatively enough to close it myself - I'd rather someone kernel-y does it.

Comment 7 Josh Boyer 2015-11-03 00:23:06 UTC
If NOTABUG doesn't do it for you, I can pick UPSTREAM or WONTFIX too.  The very clear point is we aren't going to be looking at this anytime soon.


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