VM hosts in MAAS allows for the dynamic composition of nodes from a pool of available hardware resources (e.g. disk space, memory, cores). You can create virtual machines (VMs) as needed within the limits of your resources, without concern for physical hardware. MAAS currently supports VM hosts and VMs created via Virsh.
Quick questions you may have:
- How do I start adding a VM host from the UI?
- How do I start adding a VM host using MAAS version 2.5 or higher?
- How do I add a VM host using MAAS versions below 2.5?
- How do I add a VM host manually?
- How do I set up a libvirt network for VM hosts?
- How do I set up SSH when manually adding a VM host?
- What are the detailed steps for adding a VM host?
- How do I configure a VM host after I’ve added it?
VM hosts are particulary useful for Juju integration, allowing for dynamic allocation of VMs with custom interface constraints. Alternatively, if you would like to use MAAS to manage a collection of VMs, the robust web UI allows you to easily create and manage VMs, logically grouped by VM host. Conspicuous features include:
- Juju integration
- At-a-glance visual tools for easy resource management
- Set overcommit ratios for physical resources such as CPU and RAM
- Assign VMs to resource pools to segregate your VMs into logical groupings
- Track VM host storage pool usage and assign default storage pools
- Create VMs on multiple networks, specified by space, subnet, VLAN, or IP address
Adding a VM host
After installing MAAS, the ‘VM host’ page is typically empty:
Once MAAS has enlisted, commissioned, and acquired a newly-added machine, you can deploy it as a VM host:
Once MAAS has enlisted, commissioned, and acquired a machine, you can deploy it as a VM host:
maas $PROFILE machine deploy <system_id> install_kvm=True
Setting up a manual VM host in 2.5 or on an older version of MAAS requires more steps.
Set up a `maas` libvirt network
Libvirt by default creates a virtual bridge,
virbr0, through which VMs communicate with each other and the Internet. DHCP, supplied by libvirt, automatically assigns an IP address to each VM. However, to enable network booting in MAAS, you’ll need to provide DHCP in MAAS and either:
- Disable DHCP on libvirt’s
- Create a new libvirt network
maaswith DHCP disabled.
You can set up such a
maas network like this:
cat << EOF > maas.xml <network> <name>maas</name> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <dns enable="no" /> <bridge name='virbr1' stp='off' delay='0'/> <domain name='testnet'/> <ip address='172.16.99.1' netmask='255.255.255.0'> </ip> </network> EOF virsh net-define maas.xml
Note that this network also has NAT port forwarding enabled to allow VMs to communicate with the Internet at large. Port forwarding is very useful in test environments.
Set up SSH
For MAAS to successfully communicate with libvirt on your VM host machine, this example command must succeed from every rack controller as user
virsh -c qemu+ssh://$USER@$VM_HOST_IP/system list --all
$USER is a user on your VM host who is a member of the
libvirtd Unix group on the VM host, and
$VM_HOST_IP is the IP of your VM host.
It’s essential to enforce usage of IP addresses to avoid domain name conflicts, should different controllers resolve the same domain name with different IP addresses. You should also avoid using 127.0.0.1 when running multiple controllers, as it would confuse MAAS.
MAAS package installs
maas user on your rack controllers will issue all virsh commands. Therefore, you’ll need to set up SSH public keys on every rack controller for user
If you installed MAAS via packages, first create SSH keys on all rack controllers:
sudo chsh -s /bin/bash maas sudo su - maas ssh-keygen -t rsa -N ''
Next, add the contents of
~maas/.ssh/id_rsa.pub to the VM host user’s
~$USER/.ssh/authorized_keys. To accomplish this, log into your VM host node, via SSH, from a host for which MAAS has a matching public SSH key.
MAAS snap installs
If you installed MAAS via snap, then create the needed SSH keys this way:
sudo mkdir -p /var/snap/maas/current/root/.ssh cd /var/snap/maas/current/root/.ssh sudo ssh-keygen -f id_rsa
Finally, you’ll need to add
id_rsa.pub to the
authorized_keys file in
<vm-host-user-homedir-name> is the name of your VM host user.
Insufficient permissions for
$USER may cause the
virsh command to fail with an error such as
failed to connect to the hypervisor. Check the
$USER group membership to make sure
$USER is a member of the
Now, add a VM host by using the ‘Add VM host’ button:
Here, ‘Virsh address’ typically looks like the following:
qemu+ssh://<vm host IP>/system
MAAS will automatically discover and store the resources your VM host contains. Any existing machines will also appear on the ‘Machines’ page, and MAAS will automatically attempt to commission them.
Add with CLI
Create a VM host:
maas $PROFILE vm-hosts create type=virsh power_address=qemu+ssh://firstname.lastname@example.org/system
Create a VM host with overcommitted resources:
maas $PROFILE vm-hosts create type=virsh power_address=qemu+ssh://email@example.com/system \ power_pass=example cpu_over_commit_ratio=0.3 memory_over_commit_ratio=4.6
Create a VM host that uses a default storage pool:
maas $PROFILE vm-hosts create type=virsh power_address=qemu+ssh://firstname.lastname@example.org/system \ power_pass=example default_storage_pool=pool1
KVM hosts have several configuration options. Modify these by selecting the ‘Configuration’ tab and clicking ‘Edit’. Options include a VM host’s location, password, network zone, and default resource pool.
Overcommitted resources are those allocated beyond what’s available in the physical resource. Using sliders on the configuration page, you can limit whether MAAS will attempt to overcommit CPU and memory. The input fields to the right of the sliders accept floating-point values from 0 to 10, with a default value of 1.
The following shows theoretical examples of these ratios and how they affect physical resource allocation:
8 physical CPU cores * 1 multiplier = 8 virtual CPU cores
8 physical CPU cores * 0.5 multiplier = 4 virtual CPU cores
32 physical CPU cores * 10.0 multiplier = 320 virtual CPU cores
128GB physical memory * 5.5 multiplier = 704G virtual Memory
Overcommitting resources allows a user to compose many MAAS-managed machines without worrying about the physical limitations of the host. For example, on a physical host with four cores and 12 GB of memory, you could compose four virsh machines, each using two cores and 4 GB of memory. This arrangement overcommits the available physical resources. Provided you never run all four VMs simultaneously, you would have all the benefits of MAAS-managed VMs without over-taxing your host.