Working in pairs, you will build a Linux-based virtualization host server on hardware provided in the class.
NOTE: get into the habit of logging into the server as a normal user, and try to avoid logging in as “root”. You will see a prompt which ends with $. It’s advisable to disable logging in as root directly over SSH (not covered here).
If there is a single command you wish to run as root, prefix it with sudo. If you have a series of commands to run as root, start a root shell with sudo -s, and the prompt will change to #. When you have finished, type exit to leave the root shell.
Please feel free to try these if time is available, or use them as reference material.
You can create ‘storage pools’ to make them available to libvirt. Here is how to set up an LVM pool. Do this as root on your hostX.ws.nsrc.org machine. You can create the file “ganeti.xml” wherever you want. We’ll create the file in the /root directory.
If you are not already root, then do:
$ sudo -s
And, then:
# cd /root
# editor ganeti.xml
Add the following lines to the new file:
<pool type="logical">
<name>ganeti</name>
<target>
<path>/dev/ganeti</path>
</target>
</pool>
Save and exit from the file and do:
# virsh pool-define ganeti.xml
# virsh pool-list --all
# virsh pool-start ganeti
# virsh pool-autostart ganeti
# virsh pool-list
Now you have the option of creating VMs within the “ganeti” pool, which will create logical volumes in that volume group.
The virt-install tool allows you to create and start a VM, allocate disk and attach CD image, without having to write XML and without having to use the virt-manager GUI.
This is very useful if you want to do all your management using virsh CLI.
First let’s be sure we have the virtinst program intalled: ~~~ # apt-get install virtinst ~~~
This program may already be installed. That is fine if it is.
The next command will start an Ubuntu 18.04.3 LTS install and you will be able to access the console of the isntaller using your VNC Viewer on your desktop or laptop. Note the password below (“xyzzy”) - You will need this when connecting via your VNC Viewer.
You can copy this entire command as the backslashes (“") mean newline in Linux. Paste this command (minus the initial”#" symbol) in to your host machine’s (hostx.ws.nsrc.org) terminal window:
# virt-install --name foo --ram 512 \
--cdrom /var/lib/libvirt/images/ubuntu-18.04.3-server-amd64.iso \
--disk pool=default,size=4 --network=bridge:br-lan \
--noautoconsole --graphics vnc,listen=0.0.0.0,password=xyzzy
(Use pool=ganeti,size=4 if you have set up an LVM storage pool and want to use a logical volume rather than an image file)
With --noautoconsole it does not attempt to start the virt-viewer X11 application to attach to the console. Instead, you can use a VNC viewer on your laptop to connect to the console.
To find out which VNC port to connect to, type:
# virsh vncdisplay foo
This will return something like :0 or :2 which is the VNC display number. (Add 5900 to get the VNC TCP port number).
Start your VNC viewer, tell it to connect to hostX.ws.nsrc.org:<N> and you should have a password-protected graphical console onto the VM. Remember, in this case the password is what was specified in the command above, or “xyzzy”.
You could install another Ubuntu 18.04.3 instance on your host machine, but instead let’s exit from the installer and continue on to the next exercise. To do this select “Go Back” until you see a list of all install steps available. Scroll down to “Abort the installation”, say “Yes” and you should be ready to continue.
On your host server, verify that your “ubuntu1” virtual machine is running:
$ virsh list --all
If you see:
Id Name State
----------------------------------------------------
- foo shut off
- ubuntu1 shut off
Then you need to start your ubuntu1 instance again:
# virsh start ubuntu1
If it was already “running” then you can just continue. Now try connecting to the serial port of your VM:
$ virsh console ubuntu1
Hit Enter a few times and you should find nothing happens. This is because the VM isn’t configured to give a login prompt on the serial port. Press ctrl and ] (right-hand square bracket) together to exit.
Firstly, let’s check that VM does have an emulated serial port, by editing the XML:
$ virsh edit ubuntu1
If you get a prompt like this:
Select an editor. To change later, run 'select-editor'.
1. /bin/nano <---- easiest
2. /usr/bin/vim.basic
3. /usr/bin/vim.tiny
4. /bin/ed
Choose 1-4 [1]:
You can choose “1” for a simple to use editor. If you know how to use the “vi” editor, then select “2”. We strongly suggest not selecting 4. You should only see this prompt one time.
Once you have selected your default editor to use for virsh, Scroll down and check that it contains the following 6 lines:
<serial type='pty'>
<target type='isa-serial' port='0'/>
<model name='isa-serial'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
You may have to scroll quite a ways (possibly 70+ lines).
If it does, you can exit the editor without saving.
If not, then scroll down until you find the section defining the mouse:
<input type='mouse' bus='ps2'/>
and insert the 6 lines of serial and console XML from above, before this line. Exit the editor, then reboot the virtual machine.
Now login to the virtual machine itself (using the graphical console as you have been doing so far), or you can use an ssh client if you prefer.
To enable the serial console, we need to tell systemd to enable a getty service on the serial port:
# systemctl enable serial-getty@ttyS0.service
It should say:
Created symlink /etc/systemd/system/getty.target.wants/serial-getty@ttyS0.service → /lib/systemd/system/serial-getty@.service.
Now, start the service:
# systemctl start serial-getty@ttyS0.service
Check that there is now a “getty” process running on ttyS0:
# ps auxwww | grep ttyS0
Now go back to a command line on the host server. On there, type:
$ virsh console ubuntu1
and then hit Enter. You should this time get a login prompt. Congratulations, you are now using the emulated serial port (which doesn’t require any GUI to get into). Why use a serial console ? In case you lose network access to your virtual machine, and you cannot easily get access to the graphical desktop of your Host machine (if it is for example in a server room somewhere), then the virtual console will let you access your Linux server.
Login to test, then hit Ctrl and ] (right-hand square bracket) to disconnect from the emulated serial console.
Note: there’s a way to make ttyS0 become an additional console to the graphical console. You do not need to do this now, but read on to find out.
This is done by editing /etc/default/grub on the VM itself (as the user root) and finding the line:
GRUB_CMDLINE_LINUX=""
and replacing it with:
GRUB_CMDLINE_LINUX="console=tty1 console=ttyS0,115200"
These save the file and exit.
This tells the GRUB bootloader to boot the Linux kernel with TWO consoles:
Once this is done, you can rebuild the GRUB options file:
# grub-mkconfig -o /boot/grub/grub.cfg
… and at next reboot, the virtual machine would use ttyS0 in addition to tty1 (the graphics VGA console).
By default, virt-manager creates QCOW2 storage files.
If you want to create a different format, e.g. raw, or create an image in a different storage pool, this is what you do.
When creating a virtual machine, at step 4 of 5 (“Enable storage for this virtual machine”) click “Select or create custom storage”, then “Manage…”.
At this point you can select a storage pool from the left-hand pane and click New Volume (first computer icon next to the “Volumes” text). This allows you to choose a name for the volume and its format (e.g. raw) and size. Note that you cannot choose the format if you choose an LVM based storage pool - therefore choose the default pool to create a disk image in raw format.
At this point you can decide if you want to allocate all space in the raw file, or if you want to create it sparse - this means that very little or no space will be used by the disk image until you start writing data to it, and then it will grow as required.
When the volume has been created, select it in the right-hand pane, then click “Choose Volume” to continue with the installation using this volume.
Snaphots are supported using the qcow2 format; the disk image file contains both the disk snapshots and the CPU/RAM state. You can try them out.
virt-manager GUI supports snapshots. To use them, click on the screen icon with the “Play” pictogram in the Virt-manager window for the VM:
Once you click on the button, a dialog is brought up which should say “No snapshot selected” on the right side, and a + button at the lower left (or the first computer icon on the lower left). Use this button to create a new snapshot. Give the snapshot a name (“before snapshot test”, or whatever you like), then click “finish”.
Once the snapshot is created (it may take a few seconds), you can log onto your VM and create a simple file in your home directory:
$ cd
$ touch somefile
$ ls -l somefile
Once you’ve created the file, go back to the Snapshots window, select the snapshot you created earlier, and click on the small “Play” icon at the bottom left (|>) (or the second computer icon on the left that is labeled “Run selected snapshot”). You will be asked if you would like to run this snapshot (revert) - this will “kill” the running VM and roll back to the previous state. ANY WORK done after the snapshot will be lost!
You can prove this as your connection to your VM should have been dropped when the snapshot was run. Reconnect to your VM and look in the home directory again and you should notice that the file “somefile” is gone.
If you want, you can also do this using the command line on your host where the VM is running:
$ virsh snapshot-create <vmname>
$ virsh snapshot-list <vmname>
$ virsh snapshot-revert <vnmame> <snapshotID>
You can try creating someting new on your VM as before and then watching how the item disappears when you revert back to the snapshot taken before the item was created.
If a machine is shutdown, you can use snapshot-revert to start it immediately at the point where the snapshot was taken.