Show page

Differences

This shows you the differences between two versions of the page.

--- scgc:laboratoare:05 [2018/03/27 20:24]
alexandru.carp
+++ scgc:laboratoare:05 [2021/10/27 19:18] (current)
maria.mihailescu [9. [5p] Running KVMs as an unprivileged user]
@@ Line 1: / Line 1: @@
-===== Laboratory 05. Native virtualization =====
+===== Native virtualization =====
 ===== Lab Setup =====
-  * We will be using a virtual machine in the [[http://cloud.curs.pub.ro/|faculty's cloud]].
+  * We will be using a virtual machine in the [[http://cloud.grid.pub.ro/|faculty's cloud]].
   * When creating a virtual machine follow the steps in this [[https://cloud.curs.pub.ro/about/tutorial-for-students/|tutorial]].
   * When creating a virtual machine in the Launch Instance window:
-    * For **Availability zone**, choose **CAMPUS**, **CI** or **hp**
     * Select **Boot from image** in **Instance Boot Source** section
-    * Select **SAISP Template v1** in **Image Name** section
+    * Select **SCGC Template** in **Image Name** section
     * Select a flavor that is at least **m1.medium**.
   * The username for connecting to the VM is ''student''
   * First, download the laboratory archive:<code bash>
-[student@saisp ~] $ cd saisp
+[student@scgc ~] $ cd scgc
-[student@saisp ~/saisp] $ wget --user=<username> --ask-password https://repository.grid.pub.ro/cs/saisp/laboratoare/lab-08.zip
+[student@scgc ~/scgc] $ wget --user=<username> --ask-password https://repository.grid.pub.ro/cs/scgc/laboratoare/lab-05.zip
-[student@saisp ~/saisp] $ unzip lab-08.zip
+[student@scgc ~/scgc] $ unzip lab-05.zip
 </code>
-  * After unzipping the archive, in the ''saisp'' directory should be present an ''iso'' image and the ''base.qcow2'' image that is going to be used throughout the exercises.
+  * After unzipping the archive, in the ''scgc'' directory should be present an ''iso'' image and the ''base.qcow2'' image that is going to be used throughout the exercises.
 <note important>
   * Please enable X11 forwarding on all ''ssh'' connections:<code bash> $ ssh -X <host> </code>
-  * When connecting as the ''root'' user and using the X11, please retrive the X credentials using the commands below: <code bash>
+  * When connecting as the ''root'' user and using the X11, please retrieve the X credentials using the commands below: <code bash>
-$ xauth add $(xauth -f /home/student/.Xauthority list | tail -1) </code>
+[root@scgc ~] xauth
+> q
+[root@scgc ~] xauth add $(xauth -f /home/student/.Xauthority list | tail -1) </code>
 </note>
@@ Line 30: / Line 31: @@
 ==== 1. [15p] Kernel-based Virtual Machine (KVM) ====
-Computational centers are using virtualization at a large scale since it gives the necessary flexibility in managing compute resources. In order to improve perfomance in a virtualized environment, processors have introduces features and specific instructions that enable guest operating systems to run uninterrupted and unmodified. The software entity that is resposable to facilitate this type of interaction between hardware and the guest OS is called a **hypervisor**.
+Computational centers are using virtualization at a large scale since it gives the necessary flexibility in managing compute resources. In order to improve performance in a virtualized environment, processors have introduces features and specific instructions that enable guest operating systems to run uninterrupted and unmodified. The software entity that is responsible to facilitate this type of interaction between hardware and the guest OS is called a **hypervisor**.
-**KVM** stands for **Kernel Virtual Machine** and is a kernel-level hypervisor that implements native virtualization. In the following tasks, we will learn how to interraction with this virtualization solution.
+**KVM** stands for **Kernel Virtual Machine** and is a kernel-level hypervisor that implements native virtualization. In the following tasks, we will learn how to interaction with this virtualization solution.
-First of all, we must verify that the underlying hardware has support for native vrtualization. The virtualization extensions name's depend on the hardware manufacturer as follows:
+First of all, we must verify that the underlying hardware has support for native virtualization. The virtualization extensions name's depend on the hardware manufacturer as follows:
    * INTEL - vmx (Virtual Machine eXtensions)
    * AMD - svm (Secure Virtual Machine)
@@ Line 41: / Line 42: @@
 Let's verify the existence of this extensions on our hardware:
 <code bash>
-[student@saisp ~] $ cat /proc/cpuinfo |grep vmx
+[student@scgc ~] $ cat /proc/cpuinfo |grep vmx
 flags           : ... vmx ...
 </code>
@@ Line 47: / Line 48: @@
 In order to use KVM we need to install the ''qemu-kvm'' package, which contains the ''qemu'' userspace tool that actually starts the virtual machines and transmits all their parameters to the hypervisor:
 <code bash>
-[student@saisp ~] $ sudo apt-get install qemu-kvm
+[student@scgc ~] $ sudo apt-get install qemu-kvm
 </code>
 Before we can start a virtual machine, we need to verify that the KVM kernel module is loaded:
 <code bash>
-[student@saisp ~] $ lsmod | grep kvm
+[student@scgc ~] $ lsmod | grep kvm
 kvm_intel             143187  0
 kvm                   455835  1 kvm_intel
@@ Line 59: / Line 60: @@
 As we can see above, besides the kvm module there is also a ''kvm_intel''. This means, at the moment, this machine can only support x86 guests using KVM. For each architecture there is a different kernel module. Loading the KVM kernel module leads to the creation of a char device ''/dev/kvm'' through which any communication is made using ''ioctl'' IO operations:
 <code bash>
-[student@saisp ~] $ ls -l /dev/kvm
+[student@scgc ~] $ ls -l /dev/kvm
 crw-rw---- 1 root kvm 10, 232 Mar 20 07:18 /dev/kvm
 </code>
@@ Line 69: / Line 70: @@
 Let's create a virtual machine with 256MB RAM (''-m''), 2 processors (''-smp'') and a storage device backed by the ''base.qcow2'' image (''-hda'') :
 <code bash>
-root@saisp:/home/student/saisp# kvm -hda base.qcow2 -m 256 -smp 2
+root@scgc:/home/student/scgc# kvm -hda base.qcow2 -m 256 -smp 2
 </code>
@@ Line 75: / Line 76: @@
 Let's verify the resources used for this virtual machine by inspecting the ''/proc'' filesystem. After opening a new terminal on the host system, check the kvm threads running:
 <code bash>
-root@saisp:~# ps -eLf |grep kvm
+root@scgc:~# ps -eLf |grep kvm
 root     18199 18189 18199  2    4 18:09 pts/5    00:00:00 qemu-system-x86_64 -enable-kvm -hda base.qcow2 -m 256 -smp 2
 root     18199 18189 18200  0    4 18:09 pts/5    00:00:00 qemu-system-x86_64 -enable-kvm -hda base.qcow2 -m 256 -smp 2
@@ Line 84: / Line 85: @@
 Stop the KVM machine by using ''CTRL + C'' in the console used to start it. Start a new machine that now has 4 processors and 512MB of RAM. Show again the KVM threads running:
 <code bash>
-root@saisp:~# ps -eLf |grep kvm
+root@scgc:~# ps -eLf |grep kvm
 root     18564 18189 18564  2    6 18:12 pts/5    00:00:00 qemu-system-x86_64 -enable-kvm -hda base.qcow2 -m 512 -smp 4
 root     18564 18189 18565  0    6 18:12 pts/5    00:00:00 qemu-system-x86_64 -enable-kvm -hda base.qcow2 -m 512 -smp 4
@@ Line 97: / Line 98: @@
 === Display export via VNC ===
-When interracting with vms we do not usually want to start the console in foreground, but rather start the vm in background and just in case we need access to its terminal, connect to its console. Using the ''-vnc'' option, the ''kvm'' will start a VNC server and will export the vm's console through it:
+When interacting with vms we do not usually want to start the console in foreground, but rather start the vm in background and just in case we need access to its terminal, connect to its console. Using the ''-vnc'' option, the ''kvm'' will start a VNC server and will export the vm's console through it:
 <code bash>
-root@saisp:/home/student/saisp# kvm -hda base.qcow2 -m 512 -smp 4 -vnc :1
+root@scgc:/home/student/scgc# kvm -hda base.qcow2 -m 512 -smp 4 -vnc :1
 </code>
 Still, the kvm process is in foreground. We need to add the ''--daemonize'' parameter:
 <code bash>
-root@saisp:/home/student/saisp# kvm -hda base.qcow2 -m 512 -smp 4 -vnc :1 -daemonize
+root@scgc:/home/student/scgc# kvm -hda base.qcow2 -m 512 -smp 4 -vnc :1 -daemonize
 </code>
-The ''--vnc :1'' parameter enables the VNC server on port #1 of the protocol. In order to find the exact TCP port that the VNC server is listening, wee need to add ''5900'' to the number used as ''--vnc'' argument, in our case ''5901''. We can verifty this using the ''netstat'' command:
+The ''--vnc :1'' parameter enables the VNC server on port #1 of the protocol. In order to find the exact TCP port that the VNC server is listening, wee need to add ''5900'' to the number used as ''--vnc'' argument, in our case ''5901''. We can verify this using the ''netstat'' command:
 <code bash>
-root@saisp:/home/student/saisp# netstat -tlpn
+root@scgc:/home/student/scgc# netstat -tlpn
 </code>
-The KVM machine is running in the background and we can interract with it only by connecting to its VNC exported console on port 5901 using the ''vncviewer'' tool from package ''xtightvncviewer'':
+The KVM machine is running in the background and we can interact with it only by connecting to its VNC exported console on port 5901 using the ''vncviewer'' tool from package ''xtightvncviewer'':
 <code bash>
-root@saisp:/home/student/saisp# vncviewer localhost:5901
+root@scgc:/home/student/scgc# vncviewer localhost:5901
 </code>
@@ Line 125: / Line 126: @@
 In the next steps, we will create a new qcow2 image in which we will install an OS from a ''iso'' image. For this task, the ''qemu-img'' tool is used (if not installed on the system, package ''qemu-utils'' has the tool).
 <code bash>
-root@saisp:/home/student/saisp# qemu-img create -f qcow2 virtualdisk.qcow2 1G
+root@scgc:/home/student/scgc# qemu-img create -f qcow2 virtualdisk.qcow2 2G
-Formatting 'virtualdisk.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 lazy_refcounts=off
+Formatting 'virtualdisk.qcow2', fmt=qcow2 size=2147483648 cluster_size=65536 lazy_refcounts=off refcount_bits=16
 </code>
-The first argument of the ''qemu-img'' tool is the command, in our case ''create''. The type of image to create needs to be specified (''-f qcow2''), the name of the virtual disk (''virtualdisk.qcow2'') and also its maximum dimension (''1G'').
+The first argument of the ''qemu-img'' tool is the command, in our case ''create''. The type of image to create needs to be specified (''-f qcow2''), the name of the virtual disk (''virtualdisk.qcow2'') and also its maximum dimension (''2G'').
-The installation process takes as input an installation CD (in the ''.iso'' format). The ''kvm'' command enables us to add a ''cdrom'' device. Use the ''debian-7.3.0-amd64-netinst.iso'' image as the parameter of ''-cdrom'' and the virtual disk previously created mounted on ''-hda'':
+The installation process takes as input an installation CD (in the ''.iso'' format). The ''kvm'' command enables us to add a ''cdrom'' device. Use the ''debian-10.3.0-amd64-netinst.iso'' image as the parameter of ''-cdrom'' and the virtual disk previously created mounted on ''-hda'':
 <code bash>
-root@saisp:/home/student/saisp# kvm -hda virtualdisk.qcow2 -cdrom debian-7.3.0-amd64-netinst.iso -m 256 -smp 2
+root@scgc:/home/student/scgc# kvm -hda virtualdisk.qcow2 -cdrom debian-10.3.0-amd64-netinst.iso -m 256 -smp 2
 </code>
-The virtual image will boot from the CD because no bootloader is on the virtual disk. Start the instalation process using the default steps. From this point on, the instalation is exactly the same as using real hardwae.
+The virtual image will boot from the CD because no bootloader is on the virtual disk. Start the installation process using the default steps. From this point on, the installation is exactly the same as using real hardware.
-Once the instalation has started, stop the virtual machine using one of the aforementioned methods and delete the virtual disk image.
+Once the installation has started, stop the virtual machine using one of the aforementioned methods and delete the virtual disk image.
 ==== 3. [10p] Add new resources to a KVM ====
-O usual configuration of a VM consists of 2 virtual disks: one main disk that hosts the OS and a second one that hosts the actual user data.
+A usual configuration of a VM consists of 2 virtual disks: one main disk that hosts the OS and a second one that hosts the actual user data.
 Create a new virtual disk in the ''qcow2'' format, with a 1G maximum size and attach it to a VM that has as a main disk the ''base.qcow2'' image. The virtual machine should have 256MB and 2 cpus. **Hint : -hdb**.
-Notive that the size of the new qcow2 image is extremely small. This is because the qcow2 format does not pre-allocate the maximum size of data beforehand, but rather it just expands when the user writes to it.
+Notice that the size of the new qcow2 image is extremely small. This is because the qcow2 format does not pre-allocate the maximum size of data beforehand, but rather it just expands when the user writes to it.
 <code bash>
-root@saisp:/home/student/saisp# du -sh <image-name.qcow2>
+root@scgc:/home/student/scgc# du -sh <image-name.qcow2>
 </code>
 After you have started the VM, check for the ''/dev/sdb'' block device and then create 2 partitions, each of 500MB and format them using the ''ext4'' filesystem. Mount both partitions and create in each one of them a file of 100MB.
-Check for the size fot the image from the host system.
+Check for the size for the image from the host system.
 Stop the VM and delete the qcow2 image.
@@ Line 163: / Line 164: @@
 Create a new image that will host only the differences from the base one using the ''qemu-img'' command and its ''-b'' parameter for specifying a **backing/base image**:
 <code bash>
-root@saisp:/home/student/saisp# qemu-img create -f qcow2 -b base.qcow2 sda-vm1.qcow2
+root@scgc:/home/student/scgc# qemu-img create -f qcow2 -b base.qcow2 sda-vm1.qcow2
 Formatting 'sda-vm1.qcow2', fmt=qcow2 size=8589934592 backing_file='base.qcow2' encryption=off cluster_size=65536 lazy_refcounts=off
-root@saisp:/home/student/saisp# ls -lh sda-vm1.qcow2
+root@scgc:/home/student/scgc# ls -lh sda-vm1.qcow2
 -rw-r--r-- 1 root root 193K Mar 25 19:12 sda-vm1.qcow2
 </code>
@@ Line 177: / Line 178: @@
 ==== 5. [10p] Convert between VM image formats ====
-Another ''qemu-img'' useful command is ''convert''. We can find ourselves wanting to transform a qcow2 image in a ''.vmdk'' format (the one used by VMware virtual machines) or in a ''.vdi'' (the one used by VirtualBox), without giong through another painful instalation process.
+Another ''qemu-img'' useful command is ''convert''. We can find ourselves wanting to transform a qcow2 image in a ''.vmdk'' format (the one used by VMware virtual machines) or in a ''.vdi'' (the one used by VirtualBox), without going through another painful installation process.
 <code bash>
-root@saisp:/home/student/saisp# qemu-img convert -O vdi base.qcow2 base.vdi
+root@scgc:/home/student/scgc# qemu-img convert -O vdi base.qcow2 base.vdi
 </code>
-The ''-O'' paramater specifies the output image format. Notice how specifying the input format is not necesarry since ''qemu-img'' is capable to detect it using ''qemu-img info'':
+The ''-O'' parameter specifies the output image format. Notice how specifying the input format is not necessary since ''qemu-img'' is capable to detect it using ''qemu-img info'':
 <code bash>
-root@saisp:/home/student/saisp# qemu-img info base.qcow2
+root@scgc:/home/student/scgc# qemu-img info base.qcow2
 image: base.qcow2
 file format: qcow2
@@ Line 193: / Line 194: @@
     compat: 1.1
     lazy refcounts: false
-root@saisp:/home/student/saisp# qemu-img info base.vdi
+root@scgc:/home/student/scgc# qemu-img info base.vdi
 image: base.vdi
 file format: vdi
@@ Line 208: / Line 209: @@
 <code bash>
-root@saisp:/home/student/saisp# kvm -hda sda-vm1.qcow2 -m 256 -smp 2 -net nic,model=e1000,macaddr=00:11:22:33:44:55 -net tap,ifname=tap-vm1 -vnc :1 -daemonize
+root@scgc:/home/student/scgc# kvm -hda sda-vm1.qcow2 -m 256 -smp 2 -net nic,model=e1000,macaddr=00:11:22:33:44:55 -net tap,ifname=tap-vm1 -vnc :1 -daemonize
 </code>
@@ Line 220: / Line 221: @@
 <code bash>
-root@saisp:/home/student/saisp# kvm -hda sda-vm2.qcow2 -m 256 -smp 2 -net nic,model=e1000,macaddr=AA:11:22:33:44:55 -net tap,ifname=tap-vm2 -vnc :2 -daemonize
+root@scgc:/home/student/scgc# kvm -hda sda-vm2.qcow2 -m 256 -smp 2 -net nic,model=e1000,macaddr=AA:11:22:33:44:55 -net tap,ifname=tap-vm2 -vnc :2 -daemonize
 </code>
@@ Line 240: / Line 241: @@
 <code bash>
-root@saisp:~# brctl addbr br0
+root@scgc:~# brctl addbr br0
-root@saisp:~# ip link set dev br0 up
+root@scgc:~# ip link set dev br0 up
-root@saisp:~# brctl addif br0 tap-vm1
+root@scgc:~# brctl addif br0 tap-vm1
-root@saisp:~# brctl addif br0 tap-vm2
+root@scgc:~# brctl addif br0 tap-vm2
-root@saisp:~# brctl show br0
+root@scgc:~# brctl show br0
 bridge name     bridge id               STP enabled     interfaces
 br0             8000.8ac179cb859f       no              tap-vm1
@@ Line 250: / Line 251: @@
 </code>
-Configure IP address ''192.168.1.1/24'' on the ''br0'' and IP addresses ''192.168.1.2/24'' and ''192.168.1.3/24'' on the ''eth0'' interfaces from within the guests. Verify the connectivity between all 3 hosts.
+Configure IP address ''192.168.1.1/24'' on the ''br0'' and IP addresses ''192.168.1.2/24'' and ''192.168.1.3/24'' on the ''ens3'' interfaces from within the guests. Verify the connectivity between all 3 hosts.
 Enable routing and NAT on the hosts system so that the guests will have Internet access:
 <code bash>
-root@saisp:~# echo 1 > /proc/sys/net/ipv4/ip_forward
+root@scgc:~# echo 1 > /proc/sys/net/ipv4/ip_forward
-root@saisp:~# iptables -t nat -A POSTROUTING -o ethX -j MASQUERADE
+root@scgc:~# iptables -t nat -A POSTROUTING -o ensX -j MASQUERADE
 </code>
 where ''ethX'' is the network interface from the host system connected to the exterior.
@@ Line 264: / Line 265: @@
 Remove the tap interfaces from the bridge and then delete it:
 <code bash>
-root@saisp:~# brctl delif br0 tap-vm1
+root@scgc:~# brctl delif br0 tap-vm1
-root@saisp:~# brctl delif br0 tap-vm2
+root@scgc:~# brctl delif br0 tap-vm2
-root@saisp:~# ip link set dev br0 down
+root@scgc:~# ip link set dev br0 down
-root@saisp:~# brctl delbr br0
+root@scgc:~# brctl delbr br0
 </code>
@@ Line 283: / Line 284: @@
 Now connect to it using ''telnet'':
 <code bash>
-root@saisp:~# telnet localhost 4444
+root@scgc:~# telnet localhost 4445
 </code>
@@ Line 303: / Line 304: @@
 For system administrators, a command line interface was developed called ''virsh'' as a front-end for libvirt.
-In order to use the facilities offered by ''libvirt'' we must instal first the following packets: ''libvirt-bin'', ''virtinst'', ''virt-viewer'' and ''virt-top''. Also, if we do not intend to use libvirt as ''root'', the user should be added to the ''libvirtd'' group.
+<note>
+In order to use the facilities offered by ''libvirt'' we must first install the following packets: ''libvirt-bin'', ''virtinst'', ''virt-viewer'' and ''virt-top''. Also, if we do not intend to use libvirt as ''root'', the user should be added to the ''libvirtd'' group.
+</note>
 As a first step, we must enable the networking service provided by ''libvirt'':
 <code bash>
-root@saisp:~# virsh -c qemu:///system net-start default
+root@scgc:~# virsh -c qemu:///system net-start default
 </code>
 In order to create a KVM guest we can use the ''virt-install'' tool:
 <code bash>
-root@saisp:/home/student/saisp# virt-install --connect qemu:///system --name VM1 --hvm --ram 256 --disk path=base.qcow2,format=qcow2 --network network=default --vnc --import
+root@scgc:/home/student/scgc# virt-install --connect qemu:///system --name VM1 --hvm --ram 256 --disk path=base.qcow2,format=qcow2 --network network=default --vnc --import
 </code>
@@ Line 329: / Line 332: @@
 After running the above mentioned command, a configuration file in the XML format was created by libvirt in the following path: ''/etc/libvirt/qemu/VM1.xml''.
-In order to controll the VM we will use the ''virsh'' console. Connect to the local daemon and ''list'' the running VMS:
+In order to control the VM we will use the ''virsh'' console. Connect to the local daemon and ''list'' the running VMS:
 <code bash>
-root@saisp:~# virsh
+root@scgc:~# virsh
 Welcome to virsh, the virtualization interactive terminal.
@@ Line 345: / Line 348: @@
 Notice the state of the virtual machines and its ID (in this case 3). The following operations will be issued using this ID.
-Display the VNC port of the ''VM1'' guest using the ''vncdisplay'' command followed bu the VM ID:
+Display the VNC port of the ''VM1'' guest using the ''vncdisplay'' command followed by the VM ID:
 <code bash>
 virsh # vncdisplay 3
@@ Line 353: / Line 356: @@
 Open another terminal on the host system and connect to the VNC display using ''vncviewer'':
 <code bash>
-root@saisp:~# vncviewer :0
+root@scgc:~# vncviewer :0
 </code>
+<note important>
+The ''virsh'' utility may open a viewer for the virtual machine when starting it. You must close the viewer before being able to connect to the virtual machine.
+</note>
 Close the VNC console. The guest will continue to run in background.
@@ Line 404: / Line 411: @@
  -     VM1                            shut off
 </code>
-In pairs of 2, exchange IP addresses and ensure ssh connectivity without a password for the root user between your machines.
-Connect to your colleague's machines using ''virsh'' and list all the VMs. Use <code bash>qemu+ssh://$IP_COLLEAGUE/system</code> as the address to connect to.
-Start the VM that was previously created by him and connect with VNC to it. This is one of the most usual usecases where you have a remote server with virtualization support that hosts multiple VMs.
 Delete the VM defined previously using the ''undefine'' commmand:
@@ Line 416: / Line 417: @@
 virsh # undefine VM1
 Domain VM1 has been undefined
-virsh # list
- Id Name                 State
-----------------------------------
-VM1                  running
-</code>
-Notice that the VM is still runnning. It will disappear completely when stop it:
-<code bash>
-virsh # shutdown 6
-Domain 6 is being shutdown
 virsh # list --all
  Id Name                 State
@@ Line 431: / Line 422: @@
 </code>
-==== 9. [5p] Running KVMs as an unpriviledged user ====
+<note important>
+Note that if the VM is still running when the ''undefined'' command is issued, it will not be destroyed. It will disappear completely when it is stopped.
+</note>
+==== 9. [5p] Running KVMs as an unprivileged user ====
-Create a new system group ''kvm-users'' and add the user ''student'' to this newly created group. Configure the system so that all the users that are in this group can start and manage KVM machines.
+Create a new system group ''kvm'' and add the user ''student'' to this newly created group. Configure the system so that all the users that are in this group can start and manage KVM machines.

Resources

Laboratories

scgc/laboratoare/05.1522171492.txt.gz · Last modified: 2018/03/27 20:24 by alexandru.carp

Show page Old revisions

Media Manager Back to top