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!
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)
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.
*********** 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.
*********** 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.
create a vm setup macvtap with wireless card.
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.
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.