I have a server with a KVM/Qemu VM running Windows that I need to be reachable by other machines on my LAN.
A long time I stumbled my way into making it happen. I am a bit fuzzy on the details, but I ended up creating a virtual network bridge of some kind. Well, this whole thing broke after upgrading this server to F27, and the network simply didn't came up at all, on the entire server. There were no error messages, anywhere that I could find. The network simply didn't come up at all. Neither "ifup vnet0" nor "ifup eth0" did, apparently, anything. No error messages, no attempt to acquire the server's normal IP address via DHCP.
I quickly figured out how to disable the network bridge, and reset the guest Windows VM to use NAT to have its own network access, and I'm back in business.
Now, with the crisis averted, I'd like to figure out how to get my Windows VM back on the LAN, with its own static IP address. Originally this whole thing was set up ten or so years ago, and I guess things change, and something needs to be configured differently, but I have no idea how to do it now. Pointers to some FAQs appreciated.
Here's what little info I have. This is how things worked prior to this painfull upgrade.
/etc/sysconfig/network-scripts/eth0 is my real ethernet port. In order to regain network connectivity, I commented out the BRIDGE=vnet0 setting:
DEVICE=eth0 #BRIDGE=vnet0 HWADDR=00:30:48:FC:83:FA ONBOOT=yes OPTIONS=layer2=1 TYPE=Ethernet NM_CONTROLLED=no USERCTL=no IPV6INIT=yes DEFROUTE=yes PEERDNS=yes PEERROUTES=yes IPV4_FAILURE_FATAL=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no NAME="System eth0" #UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03 BOOTPROTO=dhcp ETHTOOL_OPTS="advertise 030"
I also had a /etc/sysconfig/network-scripts/ifcfg-vnet0, which I renamed to ifcfg-vnet0.orig. I also had to go into virt-manager, and reset the guest's virtual NIC to "Virtual network 'default': NAT" setting.
After doing that, renaming ifcfg-vnet0, and commenting out "BRIDGE=vnet0" in eth0, this server was able to acquire its usual static IP address via DHCP, and be back in business. The guest Windows VM now has network access via its NAT, but I'd like to figure out how to get it bridged back to my real LAN. The DHCP server knows both the network port's real MAC address, and the MAC address of the virtual guest VM's network port.
Before I disabled the bridge, "ifup eth0" and "ifup vnet0" just did nothing, as far as I could tell. No error messages anywhere I looked, the commands just returned, after a brief pause, but without trying to obtain the server's real IP address via DHCP. Thanks for any pointers.
Gordon Messmer writes:
On 11/16/2017 07:50 PM, Sam Varshavchik wrote:
Now, with the crisis averted, I'd like to figure out how to get my Windows VM back on the LAN, with its own static IP address.
Usually, bridged networking can be set up with virsh:
virsh iface-bridge eth0 br0 --no-stp
virt-manager itself can handle this too. But before any of that happens the physical port has to be attached to the bridge, and an IP address has to be assigned to the bridged physical port. That's the step that was not working any more.
It took some aimless poking for a while, and trying things at random, but after adding
NM_CONTROLLED=no
to networks-scripts/ifcfg-vnet0, the config settings for the bridge itself, resulted in "ifup vnet0" work again, and running dhclient to acquire the server's IP address. It was working, without this explicit setting, prior to F27.
I compared all the initscripts between their F26 and F27 versions. There were some differences but I did not immediately see anything that explains the change in behavior. Both the F26 and the F27 versions of ifup-eth were quite insistent on exit 0-ing out before running dhclient, if the device was TYPE=Bridge. I could not figure out which dominoes are responsible for kicking off dhclient for bridge devices, but whatever and wherever it is, it apparently now requires NM_CONTROLLED=no before doing so.
On 11/17/2017 04:09 AM, Sam Varshavchik wrote:
Gordon Messmer writes:
Usually, bridged networking can be set up with virsh: virsh iface-bridge eth0 br0 --no-stp
virt-manager itself can handle this too. But before any of that happens the physical port has to be attached to the bridge, and an IP address has to be assigned to the bridged physical port.
What I mean is that on an otherwise unconfigured system, you can use the command above to create the bridge device and attach the physical device to it. You do not need to do anything before running that command.
It took some aimless poking for a while, and trying things at random, but after adding
NM_CONTROLLED=no
to networks-scripts/ifcfg-vnet0, the config settings for the bridge itself, resulted in "ifup vnet0" work again
Sounds like you're running both NetworkManager and the legacy "network" service. That setting should be a no-op otherwise. I've found it's less problematic to use just one of the two. I've been using NetworkManager exclusively since bridge support was added.
-
Gordon Messmer -
Sam Varshavchik