The Linux server that you used for Assignment 1 hosts copies of the SEED Labs Ubuntu 16.04 virtual machine. Each student has their own virtual machine, and anything you save in your virtual machine should remain there as long as that virtual machine exists. Since you have root access in your VM, it is possible for you to completely mess up the VM, and if it has to be reset then you’ll lose your files. With great power comes great responsibility.
In order to “play nice” and not dominate the server resources, you should suspend your virtual machine when you are not actively working in it. Two programs have been added to the server to make this easy:
581startvm – running this command will start up your virtual machine if it has been suspended. If the VM is already running it will give an error message (you can’t start more than one VM instance).
581savevm – this command will save the full state of your currently-running VM, and suspend it so that it no longer takes up server CPU and RAM resources.
You are strongly encouraged to run 581savevm before you log out, to free up resources for other students that are working. The system is set up to occasionally scan the active VMs, and if you haven’t been logged in for a while (about 10 minutes) it will save and suspend your VM anyway. However, it’s best that you do it yourself rather than just leaving it for the system to discover.
Once your VM is running, you log in to it using SSH, just like any Linux system. Each VM has its own hostname, which is your username followed by “-vm”, so if my username is freddy then I would log in to my VM by running slogin seed@freddy-vm — note that seed is the regular SEED Lab VM account, as described in the SEED Lab write-ups. These network connections are local to the class server, and since they are not accessible from the Internet you must use SSH from the server itself. Note that there is nothing stopping you from logging in to someone else’s running VM, since all machines use the same default account and password. Don’t do this — logins are tracked, so if you cause problems in someone else’s VM, there will be consequences!
That’s all there is too it!
You have full superuser rights in your VM, so you have the capabilities to completely mess it up so that it will no longer run or boot. If this happens, contact the instructor — I can very quickly set up a clean copy of the SEED Lab VM so you can get back to work, even though you will lose all your files. Try to rescue your VM yourself first though, if that’s possible!
Each student has their own virtual machine which is allocated 1 GB of RAM, and the host machine is large enough to have all 34 VMs resident in memory at once without any problems. However, these are full hardware-virtualized VMs, so every one of these will be running a full operating system with background processes to manage various OS tasks. Furthermore, this is the standard SEED Labs image, which is also running various servers (like the MySQL database server). So while there’s enough memory to hold all VMs, contention for the CPUs would make everything very slow if all 34 of you are logged in at once (the server has two CPUs, with a total of 16 cores). Because of this, you should “play nice” and only run your virtual machine when you are logged in and actively using it. It’s also best that you don’t wait until the final 24 hours before the assignment due date, like everyone else! I hope that between people using VirtualBox on their own computers and people working at different times, the system will remain usable and responsive. If this ends up being overly-optimistic, we’ll find another solution.