User Tools

Site Tools


computing:virtmanagerhell

This is an old revision of the document!



  • virtmanagerhell
  • Jonathan Haack
  • Haack's Networking
  • netcmnd@jonathanhaack.com

Alright, I am completely re-writing this as the old notes were just out of date and incomplete. The title of this is virt-manager hell because virt-manager used to be a pain in the ass for me, but I now love it. Regardless, the name is staying the same. At any rate, this tutorial is for Debian based users who have physical hosts using an external IP (either self-hosted or VPS/data center), and want to allocate some other external IPs in their block to public-facing VMs. Every step except for one is command-line based, for ease, stability, and understanding - and I am not using network-manager or dhcpd at all. In my case, I am using a SuperMicro host which has 5 ethernet ports, including two which have IPMI functionality. In my case, I decided to allocate two external IPs to the physical host so in case I tinker with bridge settings (on the other interface), then I don't lose shell access to the box or have to hassle the Data Center for KVM egcy connection, etc. On ent8s0g0 I configured the base connection, and on ent8s0g1 I configured the bridge as follows:

sudo nano /etc/network/interfaces

That file should look like this (adjust to your use-case, ofc):

#eth0 (alt name ent8s0g) physical host base-connection
auto ent8s0g0
iface ent8s0f0 inet static
      address 8.25.76.160
      netmask 255.255.255.0
      gateway 8.25.76.1
      nameservers 8.8.8.8
#eth1 (alt name enp8s0g1) interface for bridge
auto enp8s0g1
iface enp8s0g1 inet manual
auto br0
iface br0 inet static
      address 8.25.76.159
      netmask 255.255.255.0
      gateway 8.25.76.1
      bridge_ports enp8s0g1
      nameservers 8.8.8.8

Once that's done, run ``ip a`` to make sure your primary interface connects upstream to the Data Center, and also make sure that the interface ``br0`` appears at the bottom and that the secondary interface shows it as bound to the bridge in its output. Personally, I do not like automated DNS and I find that sometimes the interface entry does not populate to resolv.conf, so I do the following so that my ``resolv.conf`` configurations stick and I don't lose upstream DNS:

sudo apt install resolvconf
echo nameserver 8.8.8.8 > /etc/resolv.conf

Next up, it is time to configure the guest / VM machine. I saw a lot of good tutorials online, but most of them got sloppy at this stage as far as interfaces and bridging was concerned, so I'll try to be clear where they were not. When you set up the new VM (not covered here), instead of relying on the NAT-based default network, change the option to “Bridge” (this is in the virt-manager GUI) and enter the name of the bridge, in my case ``br0``. (You can also use ``virsh`` for this step, but why lol - I just use X forwarding and open the GUI.) This step connects the hypervisor NIC to the virtual switch of the bridge on the physical host. Once that's done, spin up the VM and open up the Terminal (the one inside the VM). In the VM's Terminal, configure the NIC interface as follows:

sudo nano /etc/network/interfaces

This file should look like this (adjust to your use-case - and again, this is inside the VM Terminal, and not on the Terminal of the physical host):

auto ens1
iface ens1 inet static
  address 8.25.76.158
  netmask 255.255.255.0
  gateway 8.25.76.1
  nameservers 8.8.8.8

The VM interface is listed inside the guest/VM as ens1 - but remember, that's connected to the virtual switch and bridge through the previous steps, so don't worry. After this step, restart the networking service and check to see if your IP address is assigned, and do the same tweaks to resolv.conf on the VM for stability for upstream requests:

sudo service networking restart
ip a
sudo apt install resolvconf
echo nameserver 8.8.8.8 > /etc/resolv.conf

At this point, I would probably reboot and then ping each external IP from a device outside of the network of the physical host. Everything should be rosy ;>. Some folks might be concerned about ARP and such, but virt-manager handles that with the gateway entry combined with the bridge, so no need to alter proc and pass traffic, etc.

oemb1905 2021/10/29 16:39

computing/virtmanagerhell.1635549681.txt.gz · Last modified: 2021/10/29 23:21 by oemb1905