Using a libvirt hypervisor instead of OpenStack for the fleet

Running Gna! System Administration
#1

Bonjour,

This is the outcome of a coworking session with Raphaël that focused on what it would take to move the fleet to a libvirt hypervisor. There is a possibility for that to happen if Easter-eggs has the means to provide that kind of resource.

Aside from the necessary configuration for that to happen in production, the task related to Enough is here and the task related to the Hostea dashboard is here.

There is one pending question: is it possible to reverse proxy ssh ports in the same way http ports are? I think to remember it is possible but I forgot how.

1 Like
Gna! MVP February 1st, 2023
#2

Just want to put in a plug for ProxMox. It’s all libvirt/qemu under the hood, gives you an API to hit, has great support in ansible, ZFS fully integrated, and it gives you clustering for “free” so would drastically ease migrating VMs and such. It also has support available, should we need it. And for those times when a visual “pane of control” is needed, there is always the GUI.

2 Likes
#4
#5

The general idea is to:

  • Instruct libvirt to add the host interface that carries public IPs to the bridge
  • Not use nat but something like “direct?”
  • Move the network configuration out of Enough

When the hypervisor is installed, the libvirt_external_interface=eth2 variable is used to let libvirt know which interface to add to the bridge. And the list of IPv4 is provided to the DHCP server managed by libvirt.

One of them needs to be dedicated to running the bind server managing the zone representing the set of host within the hypervisor.

<devices>
  ...
  <interface type='direct' trustGuestRxFilters='no'>
    <source dev='eth0' mode='vepa'/>
  </interface>
</devices>


<forward mode="route" dev="eth0"/>

or more liberal where rules are entirely up to the host configuration

<forward mode="open"/>
#6 
<network>
  <name>enough-ext</name>
  <bridge name="virbr-enough-ext"/>
  <forward mode="route" dev="eth0"/> or <forward mode="open"/>
  <ip address="192.168.1.1" netmask="255.255.0.0">
    <dhcp>
      <range start="192.168.1.3" end="192.168.1.3"/>
      <range start="192.168.1.10" end="192.168.1.10"/>
      <range start="192.168.120.43" end="192.168.120.43"/>
    </dhcp>
    <host mac="52:54:00:00:00:02" name="bind-host" ip="192.168.1.10">
  </ip>
</network>
  • mac=“52:54:00:00:00:02” is the mac of bind-host but it does not need to be this way outside of a test environment
  • the current code assumes an IP for bind-host, derived from the DHCP range: it needs to be replaced with an IP given as a parameter

Run tests:

tests/run-tests.sh tox -e py3 -- -k test_libvirt_install -m 'libvirt_integration and not openstack_integration' tests

#7

The following pull request implements the necessary changes to define the network forward policy and the DHCP configuration used by libvirt via the Ansible configuration variables rather than being hardcoded. It comes with tests in the new hypervisor playbook where a libvirt hypervisor is provisioned within a libvirt hypervisor for testing purposes. Although it is slow because it relies on nested virtualisation, it is workable.