About VM hosting (snap/3.0/CLI)
MAAS VM hosts allow 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.
This article will help you learn:
- About VM hosts
- About VM host storage pools
- About VMs and NUMA
- About support for NUMA, SR-IOV, and hugepages
- About over-committed resources
MAAS currently supports VM hosts and VMs created with LXD VMs and VM hosts as the preferred VM hosting method. As a legacy offering, MAAS still supports VM hosts and VMs created via libvirt.
A VM host is simply a machine which can run virtual machines (VMs) by allocating resources across the VMs you want to create. If needed, you can over-commit resources, allocating more resources than actually available, so long as you don’t try to use more than the VM host has available at any one time. Once MAAS has enlisted, commissioned, and acquired a newly-added machine, you can deploy it as a VM host. Alternatively, you can create a VM host from a machine you’ve already got running.
VM hosts are particularly 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. Six 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
Simply put, a VM host is a machine which is designated to run virtual machines (VMs). A VM host divides its resources (CPU cores, RAM, storage) among the number of VMs you want to create, based on choices that you make when creating each VM. It is also possible to overcommit resources – that is, use more resources than the VM host actually has available – as long as you use the VMs carefully. Once MAAS has enlisted, commissioned, and acquired a newly-added machine, you can deploy it as a VM host.
"Storage pools” are storage resources managed by a VM host. A storage pool is a given amount of storage set aside for use by VMs. A pool can be organised into storage volumes, assigned to VMs as individual block devices.
For LXD VM hosts, each VM can be assigned a single block device from the storage pool.
Retrieve VM host storage pool information with the following command:
maas $PROFILE vm-host read $VM_HOST_ID
or, to get tabular output, try:
maas admin vm-host read 5 \ | jq -r '(["NAME","TYPE","PATH","TOTAL","USED","AVAIL"]) | (,. map(length*"-"))), (.storage_pools | [.name, .type, .path, .total, used, .available]) | @tsv' \ | column -t
MAAS provides extensive optimisation tools for using NUMA with virtual machines. Earlier versions of MAAS guarantee that machines are assigned to a single NUMA node that contains all the machine’s resources. As of 2.9, MAAS now allows you to see how many VMs are allocated to each NUMA node, along with the allocations of cores, storage, and memory. You can quickly spot a VM running in multiple NUMA nodes, and optimise accordingly, with instant updates on pinning and allocations. You can also tell which VMs are currently running.
In addition, you can get a bird’s-eye view of network configuration:
- You can see which VM NIC/bond is connected to which NUMA node.
- You can tell when a NIC is connected to a different NUMA node.
- You can tell if one of multiple NICs is not in the correct node.
- You can confirm the subnet and space connecting to a VM.
- You can confirm that a VM has the desired network properties, such as latency and throughput.
- You can identify NICs that support SR-IOV and tell how many VFs are available.
MAAS also shows hugepages information (if they are in use) and prevents overcommit when using them. Hugepages essentially allow a much larger memory cache associated with the core. This obviously reduces the number of times a core has to access memory, but because the core must swap entire hugepages, optimising usage of them can be complex. MAAS helps you create these optimisations by giving you a discrete view of hugepages associated with your VM, helping you decide whether you need to use them or not.
VM host management has been redesigned to support NUMA/SR-IOV configurations and hugepages from the API/CLI. Users can:
- See resources per NUMA node.
- See resources for VM hosts bearing NUMA nodes.
- See the alignment between VM host interfaces and NUMA nodes.
- Configure and use hugepages.
Over-committed 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 four 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
Over-committing 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 libvirt machines, each using two cores and 4 GB of memory. This arrangement over commits 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.