When installing KVM-Server via Yast2, the installation-script asked me if I would like to create a network bridge, what I answered with yes.
But as far as I see, there was none created:
eth0 Link encap:Ethernet HWaddr 8C:0F:6F:7E:BD:F3
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
My question is now how can I create a bridge from the Host wifi wlan0 to the KVM-Guest?
IP-Address to the host is assigned via DHCPD, and the IP-Address of the KVM-Guest is also no matter of importance to me!
Before anything else,
A quick question,
Are you sure you want to set up a bridging mode connection, and not NAT which is typically more usual in any case whenever you don’t absolutely need to see the Guest on your network?
It’s been awhile since I’ve looked at how KVM does it nowadays… and won’t be in front of a KVM machine with wireless soon…
But,
It’s my recollection that kind of connection isn’t the adventure it once was.
In general,
The standard procedures should be verified…
Never, ever change the “wired” ethernet network connection within the Guest. When you’re configuring devices that use HostOS bridging devices, the internal Guest network connection never changes, and this basic concept applies to all virtualization (KVM, Xen, Virtualbox, VMware, Hyper-V, etc)
Inspect and make configuration changes as necessary in the Guest Properties. In KVM/libvirt, this is the “Hardware Properties”
What options do see for your network source? MacVtap used to be required for using the wireless adapter, but shouldn’t necessarily be required today.
Inspect the properties of br0 to see if it’s bound to the wlan0 interface or not. You can do this either of two ways…a. Rung the following in a console
If no existing bridge device is configured to support the wlan0 interface, then you’ll have to create a new bridging devices that does…
Although you could create a new bridging device just for the wlan0 interface, I’d recommend you first try creating a Virtual Network instead, from the Virtual Machine Manager > Edit > Connection Details > Virtual Networks,
Create a new Virtual network configured to forward (routed) to “Any physical device”
If creating the Virtual Network works as I expect, it could replace your br0 as a bridging connection to any physical interface on your machine.
Of course that assumes that your HostOS should be configured with only one working physical network connection at a time (You can switch between, but should never for instance have both an active wired ethernet connection and an active wireless enabled at the same time), but that should be your recommended setup anyway.
Post again if what I describe doesn’t work, since I’m not able to test my recommendation with an actual KVM machine using wireless.
Supporting tsu2 here: The main question is whether you actually need a bridge device for your setup. You say the IP of the kvm guest is irrelevant to you. So you probably do not need a bridge and can use any of the options libvirt offers. Main reason to have a bridge is to allow inbound connections using static vm IPs, ie when hosting servers in your kvm vm is what you want. I never managed to get that working without a bridge. I played a lot with libvirt NAT setup but failed get inbound plus vm to vm working. Also, the KDE/Plasma Networkmanager applet cannot set up NM bridges, though NM is supposed to be able to create those. And, lastly, a kvm host behind a dhcp wifi does not really make sense to me except for quick testing or the odd windows vm that only needs outbound network. Nothing I would run a vm based kube cluster on.
Just an FYI since you stated wireless. You cannot go into yast, create a bridge and bridge it to a wireless NIC. The reason is because how the wireless NIC authenticates to the wireless AP. You break both the ability of the wireless NIC on the host to connect because you have bridged it, but the guest fails as well. The solution above in the first reply works quite well in your situation and for not sitting in front of a KVM instance his instructions were spot on.
If you are wanting to build a portable development environment where all systems can communicate with each other and the host, you can control vlans, use openflow, send vlans across multiple instances of KVM instances, etc. then you have to shim openvswitch between the KVM virtual guest systems and the host. Then you can point the virtual bridge switch to the internal interface part of the host firewall in yast and have full access whether NAT’ed or not.This is not as simple an approach, but it works perfectly. Issues with openvswitch and wicked is what drove me to this form originally and there are some known timing issues which we discussed here:
If I understand what is described here,
Understanding the architecture is faulty, so conclusions are wrong.
As I stated in my previous post,
It’s important to understand that no matter what the physical network connection is, when you are configuring network connections using bridge devices, the Guest is always configured with a wired connection. Always. This never changes. Ever.
And, this is true of all virtualization technologies.
This means that it doesn’t matter if the physical connection is WiFi, 802.3, Bluetooth, internal or external physical adapters, whether a WiFi password is required or not.
All of these physical networking characteristics are configured <only> in the HostOS and then what appears as a generic wired connection is presented to the Guest by configuring the network connection in the Guest properties.
So,
Although it has at times been a problem in KVM in the past, a few years ago this should have been addressed and KVM should not be different than any other virtualization…
As long as a bridge device is bound to the wlan0 interface, that bridge <should> provide networking to Guests.
If the bridge isn’t working, then it needs to be inspected as I described in my previous post.
The backup solution is what was required before KVM should have fixed the bridge device configuration, which is to configure a MacVtap connection, which is a way to virtually “tap” into a physical network adapter. Because this really does work in real mode, this is also what you need to do if you’re doing pen testing like running aircrack-ng. Even this should be easier than in the past… Nowadays, MacVtap is integrated into the kernel (avoids building, installing and loading/activating a kernel module), and should be a ready option in your Guest Networking properties.
As for anything related to openvswitch…
For more than 99% of all deployments, you shouldn’t need to touch openvswitch at all.
You can do a great many different types of network connections without a virtual switch.
And, unless you have a real, specific need that can’t be satisfied except by utilizing a switch I generally recommend KISS so avoid installing something that’s not needed.
An example… Take advantage that multiple machines using the same bridge device are all configured with the same NetworkID, so can see each other, and communicate with each other… only. So, functionality is similar to a VLAN or a switch. The downside of course is that this kind of network isn’t “managed” with ready-made monitoring and possible filtering and shaping. But, if you only need the most simple VLAN, consider this alternative.
To configure the networking requirements to SSH from the guest1 to host1 (skipping the steps to configure SSH)
In guest1’s properties(virtual hardware details), select any network connection that involves a bridge device (eg br0, virbr0, etc). Do not select a MacVtap connection.
Boot your guest and run “ip addr” to verify the IP address it’s been assigned or configured.
Your host1 will automatically support every kind of connection listed that the guest1 might use, you can verify if you wish by running “ip addr”
From the guest1 network address, you should be able to determine the NetworkID (the part of the address masked by the subnet mask) that should be a part of the host1 network address you need to connect to. By running “ip addr” on host1, you can determine that address.
So, for example…
Configure guest1 to use a network, it can be a NAT, Host-only, or a Bridged network.
Boot up guest1, and run “ip addr” The following is a possible result, but there is no typical result.
192.168.0.20 255.255.255.0
From this example, the masked bits which is the NetworkID is
192.168.0
In host1, you now need to run “ip addr” which will result in a number of different interfaces and at least one address for each interface listed. You’re looking for an address with a matching NetworkID so the following is an example of an address that does
192.168.0.2 255.255.255.0
So,
Now you have the host1 IP address you need to connect to from your guest1.
Note that you almost always must connect by ip address and not use hostnames because almost all configurations do not assign the same DNS server to both the host and any guest.
I complimented your solution and memory in my first post: **The solution above in the first reply works quite well in your situation and for not sitting in front of a KVM instance his instructions were spot on.
**
I took the time to actually test your solution before I replied.
You then decided my conclusion was wrong.
I then challenged you to prove yours, since the flaw was obvious in your first post. you even stated the issue! Instead you replied with a completely different design. So let me provide a screenshot. Then you can, if you want, go back and read the original post and my response, which is completely accurate.
You can do what I have in the link below with a wired connection to a bridge. Your host losses connectivity through that NIC, but the guest has access. You cannot do this with a wireless NIC, it will no longer authenticate to the network (My first statement in my OP). This is actually easier than your solution below if you have a spare NIC and need lots of VM’s since you connect them all to the same bridge, instead of building a lot of bridges in your host, and then point the bridge in the host to the internal interface of the firewall. You have complete control over them by IP, but (again my OP) you cannot VLAN tag.
I’m aware of some scenarios where the host’s routing is altered because of a bridge device and those are resolvable by fixing the routing rules, but I’m not currently aware of any basic connectivity issues which don’t require routing to a remote(different physical) machine.
That’s OK,
If anyone has a similar issue and comes across this in the future, they’ll have a start on what to look for to troubleshoot…
And this thread has taken a slight tangent as well…
