VM on UH IaaS

A good alternative to running the INF3190 exercise virtual machine (VM) on the (slow!) Ifi lab computers or on your own machine is to provision a cloud VM on the national universities and colleges cloud, UH IaaS.

All users at Norwegian higher education institutions should be able to link their accounts to UH IaaS and provision VMs using their OpenStack dashboard.

NB: access to the UH IaaS dashboard is IP-filtered. You will not be able to access the service from outside a university network, so when you are not on campus you must either use the UiO VPN or a remote desktop session. See this article on TermvaktWiki.

There is a quite comprehensive guide to using the service available here, but in the interest of brevity here is a short step-by-step guide:

First time setup

1. Browse to www.uh-iaas-no and click the "Start using service" button.
2. Click through the menus and log in with your UiO account. You will need to give your consent to transfer some account data into the Dataporten login service.
3. At the end of the account linking process you will be presented with an API token (password). You should take note of this in case you want to use some advanced features later, it is apparently not possible to recover the token at a later time! If you forget this, you can still log into the dashboard using your regular UiO account, however.

Provisioning a VM instance running the INF3190 image

This is mostly the same as the official guide to creating a Linux virtual machine, except that we will first upload a custom disk image.

Tip: if you perform this from an Ifi lab machine or via remote desktop, the file upload step will complete significantly quicker!

1. Log into the UH IaaS dashboard
2. (Optional, but recommended for better performance) Select the "osl" region by clicking on "DEMO-<username>.ifi.uio.no bgo" in the upper left corner of the page. Otherwise your VM will be physically located in Bergen.
3. In the menu on the left, navigate to Project > Compute > Images.
4. Hit the "Create image" button near the top right.
5. Specify some descriptive name for the VM image, select the "mininet-vm-x86_64-cloud.qcow2" qcow2 file and select "qcow2" as file format. The rest of the options can be left as default.
6. Hit "Create image" and wait for the image to upload.
7. In the left-hand menu, navigate to Project > Compute > Access & Security.
8. Select the "Security Groups" tab.
9. Hit "Create Security Group" and give it some name like "SSH and ICMP".
10. Click "Manage rules" on the line corresponding to your newly created group.
11. This presents you with a set of firewall rules, we will add two rules using the "Add rule" button.
12. First, pick the "SSH" rule from the dropdown and accept the default values by clicking "Add".
13. Optionally, you can allow the VM to respond to pings by repeating the previous step and picking the "ALL ICMP" rule.
14. Go back to Project > Compute > Access & Security.
15. Select the "Key Pairs" tab.
16. If you already use an SSH key pair to log into e.g. the Ifi login server, pick "Import key pair" and paste in your public key. Usually you will find this at ~/.ssh/id_rsa.pub on a *NIX machine.
17. If you have never set up SSH key pairs, you can instead choose the "Create Key Pair" button. You will later download the public key and point your SSH client at it.
18. In the left-hand menu, navigate to Project > Compute > Instances.
19. Hit "Launch instance".
20. On the "Details" tab, name your VM instance something descriptive and leave the rest as default.
21. On the "Source" tab, select your newly uploaded image by clicking the "+" next to it in the list.
22. On the "Flavor" tab, select "m1.small".
23. On the "Networks" tab, select "dualStack".
24. On the "Security Groups" tab, add the group you created earlier.
25. On the "Key Pair" tab, make sure your key pair is selected (it might be by default).
26. The rest of the options can be left in their default state. Click "Launch Instance" to provision the VM.
27. This can take a couple of minutes, wait until the instance state changes to "Running".
28. Your VM is now booting, you can watch it by clicking the "Console" button found by hitting the arrow on the far right.
29. When the VM has finished booting, you should be able to access it via SSH: "ssh mininet@<VM IP>". You will find the IP in the instance list.
30. When you've verified you can log in, you can access a remote desktop on the VM via VNC over SSH. See below.
31. Remember to keep backups of your work OFF the VM instance, and to shut it down if you are not using it for a while.

Important information

The default "DEMO" project allocation you get in UH IaaS when you link your university account is quite limited in the resources you can use. However, it is adequate for our use, so you do not need to request any more resources unless you are especially interested. Note however that instances from DEMO projects are subject to being stopped without warning by the UH IaaS administrators. Your data might be OK, but you should make very sure to keep copies/backups stored away from the VM instance. You could for example version your code in Git and make sure to push it to some remote repository whenever you make changes. This is a good idea anyway.

Remote desktop access

When your VM is up and running, you can access the graphical desktop remotely using VNC tunneled over an SSH connection. The VNC server is already set up for you on the VM.

On your own machine, you will need some VNC client. There is usually one installed on most Linux distributions, check your application menu. A common client that is launched from the command line is xfreerdp, this is installed on Ifi machines. On Mac OS X, the installed-by-default Screen Sharing application is actually a VNC client. On Windows you can for example use TightVNC. RealVNC Viewer can be run as a standalone EXE (without going through an installer), which should work fine on Ifi Windows lab machines.

Because VNC is a very insecure protocol by itself (no encryption of either authentication or screen data), we will protect the session using an SSH tunnel. The VNC server will only accept connections from the local machine, so even if you create bad firewall rules nobody will be able to access it from the outside.

On Linux or OS X, first set up the tunnel using this command:

ssh mininet@<VM IP> -L 127.0.0.1:9999:127.0.0.1:5901 -NT

This sets up a TCP listener on your local machine, port 9999 (you can pick any unused port here), which will connect to TCP port 5901 (don't change this port number!) on the VM's loopback interface, which is where the VNC server is listening. The -NT options will cause the tunnel to persist until you kill SSH e.g. with CTRL+C.

When the tunnel is set up (your terminal will appear to "hang"), you can connect to localhost:9999 using your VNC client. The password is mininet. Your desktop session will normally persist between VNC sessions as long as you don't reboot the VM.

On Windows you will need to set up the tunnel using the PuTTY configuration interface.