Virtual Networking Issues

English Virtualization
1

I have been running openSUSE 13.1 for quite a few years now and have loved it. However, I have been wanting to upgrade for many obvious reasons. I had been using the Hypervisor/Virtual Machine Manager for virtualization. In 13.1 I was able to use it straight out of the box, all of my virtual machines would get their IP addresses from my router, (I use a virtual machine to house websites) and then my router would translate the ‘ip : port_num’ to the right virtual machine and the data would get sent out.

Now in 13.2 it forces a virtual network to be used in virtualization, and it disables using both the host machine and virtual machines at the same time unless using the virtual network. Under 13.1 virtual machines and host machine could access the same network card at the same time, thereby all machines virtual and host could show up in the same local ip range (192.168.1.x) instead of now having host in my 192.168.1.x range and virtual machines in the 192.168.122.x range…

I really have been looking to figure out why this is now the case, or how to translate around it so that my virtual machines can be accessed from the internet.

Virtual machines can access the internet, I used to be able to access them remotely via vnc from my desktop without having to get into virtual machine manager using vncviewer, now I can’t because of this stupid virtual network ****… I am very frustrated, as I am sure there is a very simple answer as to where to configure the virtual network addresses to use static address or something…

any help/advice would be appreciated, otherwise I’ll have to go back down to 13.1 again, and not going to 42.1 because of this same issue in virtual machine manager and that it appears that vnc is not working right at all in 42.1 (just get a black screen when trying to access a machine in 42.1) I know that is a different issue and may ask for some support there in the future in the correct forum, right now I really need to figure out this Virtual networking stuff…

2

I’ve described this situation many times in recent posts both here in this Virtualization forum and in the Networkng forum.

Definition:
Note that the “bridging interface” I describe is a “Linux Bridging Device” which has nothing to do with configuring networking in a conventional bridging mode (far from it) but has everything to do with configuring network access so that Guests and Hosts appear the same as accessible physical machines on the network.

Describing virtual networking, and why it’s implemented:
Virtual networks are properly implemented by configuring both HostOS and Guests to use a bridging interface which might be identified as br0, virbr0, even something else depending on the application that created it. This bridging interface is very useful (compared to raw, real networking interfaces) because a number of networking features and configurations can be set and applied to all machines that use the interface… things like DNS configuration, DHCP yes/no, DHCP scope, more. If Guests accessed the physical network directly, you would not be able to manage your networking as a group, each machine would have to be configured individually only.

And, if you configure your virtual networking as DHCP enabled, usually you won’t see any issues at all.
Or, I’ve noticed that if you use Network Manager you won’t likely see any problems as well.

When you’ll see your Problem:
But, I’ve noticed that if you configure your clients in bridging mode <and> use “Classical ifup/ifdown” or Wicked as you’ve done that the HostOS no longer can “see” the default gateway because the original, physical interface is no longer being used. You should be able to verify this by running the following command

ip route

Fixing the Problem:
Once you have analyzed and discovered this to be the case, then the solution should be clear…
YAST > Network Settings > Routing tab
For your network interface, on the right you’ll find a dropdown.
Change the dropdown selection from your physical interface to the appropriate bridging interface. Remember, I said that bridging interfaces can be configured in multiple ways so you see multiple options but if you haven’t done much configuration you probably will see only one besides the physical interface.

You need to restart network services, or YAST might do that for you automatically. If you have to restart network services, run the following command

systemctl restart network.service

Everything should now be functioning properly.

TSU

3

Thanks for your reply, I have felt I have had a strong understanding of the basics of networking, but by no means a master. However, this makes little to no sense to me.

In 13.1 it worked exactly as I wanted it to. All of my virtual machines received their dhcp and dns information from my router. In that case my host machine and all virtual machines showed as being in the same network (all in 192.168.1.x range) and therefore I could vnc into each machine as I pleased and use virtual machines to host a variety of servers for my home network (video server, music server, etc…) most of them were then configured to use samba so that any machine in the house would be able to access the desired information. In that configuration a virtual machine behaved exactly as I want it to, to look like any other real machine on my network. And by openning the proper ports I could access all of my machines, real and virtual, from the internet…

So I do not understand the statement

things like DNS configuration, DHCP yes/no, DHCP scope, more. If Guests accessed the physical network directly, you would not be able to manage your networking as a group, each machine would have to be configured individually only.

because now virtual machines are not behaving like any other real machine on my network. And configuring one individually, especially when they are servers and I want them to have static ip addresses, is what I do by dhcp in my router with manual assignments based on mac addresses. So I do not see this supposed benefit at all that you are speaking of.

Currently I am running NetworkManager Service because every time I run Wicked then vnc into my host machine is then broken. Either case I can access the internet from the host, but can only access the host via vnc with NetworkManager Service running in 13.2. This is another issue also was not a problem in 13.1

and the ip route info

me@host_machine:~> ip route
default via 192.168.1.1 dev enp0s25 proto static metric 1024
192.168.1.0/24 dev enp0s25 proto kernel scope link src 192.168.1.5

and am able to vnc into my machine while using NetworkManager Service

me@host_machine:~> vncviewer 192.168.1.5:5901

TigerVNC Viewer 64-bit v1.4.1
Built on: ??-??-?? ??:??
Copyright (C) 1999-2014 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.

Sun Feb 21 10:17:34 2016
CConn: connected to host 192.168.1.5 port 5901
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8

Sun Feb 21 10:17:35 2016
CConnection: Choosing security type None(1)
X11PixelBuffer: Using default colormap and visual, TrueColor, depth 24.
CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
CConn: Using Tight encoding
CConn: Enabling continuous updates

when I looked at the info in yast, then when using NetworkManager Service br0 is greyed out and I can not access its info, so I switched to Wicked and am now able to select br0.

new ip route info:

me@host_machine:~> ip route
default via 192.168.1.1 dev br0 proto dhcp
default via 192.168.1.1 dev enp0s25 proto static metric 1024
192.168.1.0/24 dev enp0s25 proto kernel scope link src 192.168.1.5
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.5

But now vnc is broken because Wicked is being used. The backround image displays for less than a second, no login screen, and then the window closes with the error Connection reset by peer (104)

me@host_machine:~> vncviewer 192.168.1.5:5901

TigerVNC Viewer 64-bit v1.4.1
Built on: ??-??-?? ??:??
Copyright (C) 1999-2014 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.

Sun Feb 21 10:26:15 2016
CConn: connected to host 192.168.1.5 port 5901
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
CConnection: Choosing security type None(1)
X11PixelBuffer: Using default colormap and visual, TrueColor, depth 24.
CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
CConn: Using Tight encoding
CConn: Enabling continuous updates
CConn: read: Connection reset by peer (104)

Anyway, now I will ignore that vnc is now not working and try to move forward with getting my virtual machines to work right. I openned Virtual Machine Manager, right clicked on localhost(xen) and selected details. In the virtual networks tab it still shows virbr0, start the virtual machine and following is its ip route info:

me@virtual_machine:~> ip route
default via 192.168.122.1 dev eth0
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev eth0 scope link
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.101

so I go into the information tab on my virtual machine, go to the virtual network interface, change network source from ‘Virtual Network: Default (NAT)’ to ‘Specify shared device name’ and then type in br0 in bridge name, then restart the virtual machine, received exact same info from ip route in virtual machine. No luck there so reverting back to the default (NAT) setting…

So the next idea is to create a different virtual network.

Right click on localhost(xen), select details, in virtual networks select the plus sign to create a new virtual network and follow through the wizard.
Step 1 of 4: I name it virtnet
Step 2: I want it on my regular network and choose 192.168.1.0/24 as the network space, deselct DHCPv4 as I want my router to assign the addresses,
Step 3: I leave the IPv6 deselected as it is currently not needed,
Step 4: I do not want an isolated network so I change to Forwarding to physical network, does not offer any other options but Any physical device and leave the mode as NAT, click finish.

weird, I have done this a hundred times before (while using NetworkManager Service) and it has always errored at this point stating something along the lines of already using the physical network, but this time virtnet is added to my list of virtual networks… open the virtual machine, go to info > virtual network interface> and select the virtnet option that is now showing. Clicked start to start the virtual machine. but it still has the same ip route info, but now also can not connect to the internet… now my head hurts again and am setting everything back to how it was before this post…

Naturally it should be very apparent I do not understand the changes that were made between 13.1 and 13.2 and how those changes are even remotely beneficial to what I want to do. I am very willing to learn how this is beneficial, but I see no documentation on the options present or how to do the things I want. If there is documentation I am not finding it and any links would be greatly appreciated as would be any idea on how to configure this the way I would like it to work.

4

First, <on the HostOS>

It’s important whether you’re running Wicked or Network Manager.
I don’t know what the ramification might be to use Network Manager in combination with “ifup/ifdown” settings, but I can’t imagine any scenario where that might result in a clear, successful solution.

So, at least for now, let’s take a look at what you should do when you configure using a HostOS using Wicked.
That should be the first setting in YAST > Network Settings > Global Options tab

The next step should be to configure your network interface, open YAST > Network Settings > Overview tab.
If you created a bridge device when you ran “Install Hypervisor and Tools” then you should see a br0 interface. If you created a virtual network using vm manager you might see a virbr0 interface. You might see a bridge device but named differently if you created your bridging device using some other tool. If you don’t see a br0, virbr0 or similar device, then post you don’t see something like that.

The following is a screenshot of one of my machines with the br0 interface highlighted.

789×623 24 KB

Configure the bridge device as either a DHCP client or with static settings.

In this case, the br0 interface is configured with DNS settings automatically, but if you are configuring a static address you will need to configure YAST > Network Settings > Hostname/DNS tab.

In my case, because my br0 is configured as a DHCP client, the default gateway should be automatically configured but if you are configuring a static address, then you <must> configure your YAST > Network Settings > Routing tab. In the following screenshot the values are empty because the br0 interface is configured using DHCP, but if configuring a static address, then an IPv4 address would need to be entered <and> you need to click the dropdown to the far right and select the br0 interface. I’ve created a red box around this option in the following screenshot.

789×623 26 KB

OK,
Now that your Host is properly set up, now go into each one of your Guest’s properties and set their networking to attach to br0, not virbr0. Although br0 and virbr0 are likely both set up as bridging virtual networks, they are <different> virtual networks so of course if any Guest or the Host is connected to one of the two, it should see all connected to that same bridging device but won’t be able to connect to any machine connecting through the other bridging device (After all, they are two completely separate networks). So, with both your HostOS and your Guests all connected to the same bridging device (I’ve arbitrarily selected br0) they should now be able to see and connect to each other.

You should also be able to connect using VNC or any other app.

Once you’re convinced all are working as they should, I’d recommend cleaning up by removing virbr0 if it’s configured as a bridging virtual network since it likely duplicates what br0 does. But, if virbr0 is configured as a NAT network, then you should leave it alone since a NAT virtual network is different functionality than what br0 provides.

HTH,
TSU

5

Thank you so much for your help. All is now working!

6

That’s great!

TSU