Salt as a Cloud Controller¶

Setting up Hypervisors¶

The first step to set up the hypervisors involves getting the correct software installed and setting up the hypervisor network interfaces.

libvirt:
  pkg.installed: []
  file.managed:
    - name: /etc/sysconfig/libvirtd
    - contents: 'LIBVIRTD_ARGS="--listen"'
    - require:
      - pkg: libvirt
  virt.keys:
    - require:
      - pkg: libvirt
  service.running:
    - name: libvirtd
    - require:
      - pkg: libvirt
      - network: br0
      - libvirt: libvirt
    - watch:
      - file: libvirt

libvirt-python:
  pkg.installed: []

libguestfs:
  pkg.installed:
    - pkgs:
      - libguestfs
      - libguestfs-tools

eth0:
  network.managed:
    - enabled: True
    - type: eth
    - bridge: br0

br0:
  network.managed:
    - enabled: True
    - type: bridge
    - proto: dhcp
    - require:
      - network: eth0

libvirt_keys:
  virt.keys

Getting Virtual Machine Images Ready¶

Salt Virt, requires that virtual machine images be provided as these are not generated on the fly. Generating these virtual machine images differs greatly based on the underlying platform.

Virtual machine images can be manually created using KVM and running through the installer, but this process is not recommended since it is very manual and prone to errors.

Virtual Machine generation applications are available for many platforms:

kiwi: (openSUSE, SLES, RHEL, CentOS)

https://opensuse.github.io/kiwi/

vm-builder:

https://wiki.debian.org/VMBuilder

See also

vmbuilder-formula

Once virtual machine images are available, the easiest way to make them available to Salt Virt is to place them in the Salt file server. Just copy an image into /srv/salt and it can now be used by Salt Virt.

For purposes of this demo, the file name centos.img will be used.

Using Salt Virt¶

With hypervisors set up and virtual machine images ready, Salt can start issuing cloud commands using the virt runner.

Start by running a Salt Virt hypervisor info command:

salt-run virt.host_info

This will query the running hypervisor(s) for stats and display useful information such as the number of cpus and amount of memory.

You can also list all VMs and their current states on all hypervisor nodes:

salt-run virt.list

Now that hypervisors are available a virtual machine can be provisioned. The virt.init routine will create a new virtual machine:

salt-run virt.init centos1 2 512 salt://centos.img

The Salt Virt runner will now automatically select a hypervisor to deploy the new virtual machine on. Using salt:// assumes that the CentOS virtual machine image is located in the root of the Salt File Server on the master. When images are cloned (i.e. copied locatlly after retrieval from the file server) the destination directory on the hypervisor minion is determined by the virt:images config option; by default this is /srv/salt-images/.

When a VM is initialized using virt.init the image is copied to the hypervisor using cp.cache_file and will be mounted and seeded with a minion. Seeding includes setting pre-authenticated keys on the new machine. A minion will only be installed if one can not be found on the image using the default arguments to seed.apply.

You can also deploy an image on a particular minion by directly calling the virt execution module with an absolute image path. This can be quite handy for testing:

salt 'hypervisor*' virt.init centos1 2 512 image=/var/lib/libvirt/images/centos.img

Now that the new VM has been prepared, it can be seen via the virt.query command:

salt-run virt.query

This command will return data about all of the hypervisors and respective virtual machines.

Now that the new VM is booted it should have contacted the Salt Master, a test.version will reveal if the new VM is running.

QEMU copy on write support¶

For fast image cloning you can use the qcow disk image format. Pass the enable_qcow flag and a .qcow2 image path to virt.init:

salt 'hypervisor*' virt.init centos1 2 512 image=/var/lib/libvirt/images/centos.qcow2 enable_qcow=True start=False

Migrating Virtual Machines¶

Salt Virt comes with full support for virtual machine migration, and using the libvirt state in the above formula makes migration possible.

A few things need to be available to support migration. Many operating systems turn on firewalls when originally set up, the firewall needs to be opened up to allow for libvirt and kvm to cross communicate and execution migration routines. On Red Hat based hypervisors in particular port 16514 needs to be opened on hypervisors:

iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 16514 -j ACCEPT

Salt also needs the virt:tunnel option to be turned on. This flag tells Salt to run migrations securely via the libvirt TLS tunnel and to use port 16514. Without virt:tunnel libvirt tries to bind to random ports when running migrations.

To turn on virt:tunnel simply apply it to the master config file:

virt:
    tunnel: True

Once the master config has been updated, restart the master and send out a call to the minions to refresh the pillar to pick up on the change:

salt \* saltutil.refresh_modules

Now, migration routines can be run! To migrate a VM, simply run the Salt Virt migrate routine:

salt-run virt.migrate centos <new hypervisor>

VNC Consoles¶

Although not enabled by default, Salt Virt can also set up VNC consoles allowing for remote visual consoles to be opened up. When creating a new VM using virt.init pass the enable_vnc=True parameter to have a console configured for the new VM.

The information from a virt.query routine will display the vnc console port for the specific vms:

centos
  CPU: 2
  Memory: 524288
  State: running
  Graphics: vnc - hyper6:5900
  Disk - vda:
    Size: 2.0G
    File: /srv/salt-images/ubuntu2/system.qcow2
    File Format: qcow2
  Nic - ac:de:48:98:08:77:
    Source: br0
    Type: bridge

The line Graphics: vnc - hyper6:5900 holds the key. First the port named, in this case 5900, will need to be available in the hypervisor's firewall. Once the port is open, then the console can be easily opened via vncviewer:

vncviewer hyper6:5900

By default there is no VNC security set up on these ports, which suggests that keeping them firewalled and mandating that SSH tunnels be used to access these VNC interfaces. Keep in mind that activity on a VNC interface that is accessed can be viewed by any other user that accesses that same VNC interface, and any other user logging in can also operate with the logged in user on the virtual machine.

Conclusion¶

Now with Salt Virt running, new hypervisors can be seamlessly added just by running the above states on new bare metal machines, and these machines will be instantly available to Salt Virt.