Private Virtual Machines

From CsWiki
Jump to: navigation, search

Virtual Machines let users have a completely isolated environment with more control inside. Virtual machines emulate a complete computer which gives more control to the user, but has large resources overhead (CPU, memory and disk space) and limited access to shared resources within the CS system.

On the CS linux machines, users can use the qemu hypervisor for private virtual machines with user network stack. Users can use these VMs to test programs "natively" before trying to install them properly on the CS system.

Imporant: These virtual machines require lots of resources (cpu, memory, disk space), and should not be used for heavy runs or for production systems.

Pre installed virtual machines

There is a couple of pre installed VMs with some addition to integrate with the CS environment:

  • rundeb10: A Debian 10 VM.
  • runubuntu1804: An ubuntu 18.04 VM.

Basic Usage

To run the pre-installed debian 10 VM:


The default user is csuser (a sudoer). To know the password for csuser or for root, run:

rundeb10 -h

The virtual machine will take half the memory and half the CPUs of the host machines. To change it, use the -mem and -cpu options. E.g.:

rundeb10 -mem 1024 -cpu 0.25

This will use 1G memory and 1/4 of the available CPUs.

Saving changes

rundeb10 creates a temporary copy (snapshot) of a debian machine. All changes inside it will be lost.

To save changes for the virtual machine, a location with enough storage needs to be used. This location can be specified with the -cow option, e.g.:

rundeb10 -cow /cs/labs/<supervisor>/<user>/my-deb10.qcow2

This will create the my-deb10.qcow2 file which will save the changes.

After a qcow2 image is created and all relevant software is installed, it might be good idea to add the -snapshot option so that the image won't be accidentally corrupted by an unintended installation:

rundeb10 -cow /cs/labs/<supervisor>/<user>/my-deb10.qcow2 -snapshot

Console and GUI

The machine will open a graphical view which is usually not necessary. To work directly from the shell where rundeb10 was run (the serial console of the machine) use the -serial option:

rundeb10 -serial

Note: The -serial console will be multiplexed with the qemu monitor. This means two things:

  1. To get the qemu monitor, press <ctrl> + a. In the qemu monitor, the command quit will quit the VM.
  2. To use <ctrl> + a in the VM console (e.g. to get to the start of the line), <ctrl> + a needs to be pressed twice.

Note: With -serial, to close the VM forcibly, run the "quit" command in the qemu monitor (accessible with <ctrl> + a)

Note: The default serial console size doesn't always match the window size. As such, it is sometimes best to run resize inside the console to set up the terminal properly.

To open the graphical window in addition to the serial console:

rundeb10 -serial -graphics

To open an xterm in the current window manager with DISPLAY redirection, use the -xterm option:


This implies the -serial option. The -xterm option is good when a GUI program is required but when the entire graphical interface is not needed. It also simplifies the copy and paste between the host and the virtual machine.

Note: The -xterm option has some limitation and will not always work.

Filesystem access and permissions

To access local file systems from within the virtual machine, use the -bind option:

rundeb10 -bind /cs/labs/<supervisor>/<user>

Due to permission issues, it's best to also add the CS user inside the VM when accessing local filesystems. This can be done with the -user

rundeb10 -user

The -user option implies "-bind ~" which will bind the home directory inside the VM.

The graphical interface will still be for csuser, but xterm or serial will run under your own user. So it's best to use the -user option with -xterm or -serial:

rundeb10 -user -xterm -bind /cs/labs/<supervisor>/<user>

Note: Adding the user to the virtual machine changes some of the users databases inside the VM. As such, if you need to install things using root, it's best to start the machine without the -user option for the installation process, and restart the machine later with -user.

Note: While the user and groups will be available inside the VM, password authentication will not work.


To run a script within the VM, use -batch:

rundeb10 -batch

The script will be copied and run on the serial console (implies the -serial option).

To run a single line, use -run:

rundeb10 -user -run 'echo "********************"; echo hello; echo "********************"; sleep 30'

The line will be wrapped by /bin/bash script and will run as with the -batch option (so -serial is also implied).

The -serial, -xterm, -run and -batch run by default with csuser. To run with your own user add the -user option. To run as root instead, use the -root option e.g.:

rundeb10 -root -run 'echo "********************"; id; echo "********************"; sleep 30'

When using -xterm, -serial, -batch or -run, the VM will shutdown after exiting. To keep it alive use the -no-shutdown option:

rundeb10-xterm -no-shutdown

Creating new virtual machine

The qemu can be used directly to create you own virtual machine. First a disk image needs to be created. E.g. for a 50G harddisk:

qemu-img create -f qcow2 /cs/labs/<supervisor>/<user>/my-image.qcow2 50G

Then some installation cd needs to be obtained from somewhere. For most linuxes, a netinstall is usually the best option. To start a machine with 4 cpus and 16G RAM for installation:

qemu-system-x86_64 -m 16G -smp 4 /cs/labs/<supervisor>/<user>/my-image.qcow2 -cdrom <netinstall.iso>

Afterwards, qemu needs to be run without the -cdrom option:

qemu-system-x86_64 -m 16G -smp 4 /cs/labs/<supervisor>/<user>/my-image.qcow2

In some cases, the rundeb10 utility can be used to run the image:

rundeb10-cow /cs/labs/<supervisor>/<user>/my-image.qcow2

Note: Not all rundeb10 options will be available, but generic run options like -snapshot, -cpu, or -mem will work. -serial might work, but might need additional configuration from within the VM.


  • The qemu VM runs under the user space. As such it cannot access any resources that the user cannot access.
  • The VM is run behind a user space NAT'ed network stack:
    • Any connection into the machine will be blocked by default. While this can be somewhat mitigated, it's a security risk.
    • The network has some overhead and should not be used for intensive networking jobs.
    • Two VMs cannot see each other without some complicated ssh tunneling.
  • The current setup requires hardware support (KVM). Old machines do not have these capabilities, and some machines have it disabled in the BIOS. If it doesn't work on a specific machine, please contact to see how to solve it.

Additional info