Commit 3e83ed8e authored by lcfib's avatar lcfib
Browse files

Added documentation about integration RAVADA - OpenGnsys

parent 4bfc3f63
.. Ravada VDI documentation
Integrating Ravada and OpenGnsys
Dani Sanchez - 28/Nov/2018
Integrating Ravada and OpenGnsys
Opengnsys is a open source project for remote deployment. This is a project developed for many Spanish universities to provide a full tool to deploy, manage, clone and manage remote computers. Opengnsys allow distribute and install many different operating systems.
Opengnsys is based in a PXE boot and a Linux graphical agent that allows manage remotely the computer from a centralized console. Here, we will explain how adapt our RAVA system to support boot from Opengnsys. The final objective is automate the creation a virtual machine with the same image that we have created for our classrooms.
DHCP boot options
First of all, we have to provide the dhcp options ``next-server`` and ``filename``. to our dhcp server. Ravada is a KVM-based solutions, so, the dhcp server is the standard integrated in KVM. The DHCP-KVM server allows some configurations. Edit the KVM network configuration and add these options to the dhcp section:
.. prompt:: bash $
virsh#virsh net-edit default
<forward mode='nat'/>
<bridge name='virbr0' stp='on' delay='0'/>
<mac address='52:54:00:1a:06:50'/>
<ip address='' netmask=''>
<tftp root='/'/>
<range start='' end=''/>
<bootp file='grldr' server='<opengnsys-server-ip'/>
``grldr`` is the standard boot loader for Opengnsys.
Create and empty virtual machine
Now, you have to create and empty virtual machine. And empty machine boots from the iPXE network boot firmware client integrated in KVM. This is a snapshot of a vm booting process:
.. image:: images/opengnsys_boot_pxe.png
NAT adaptation
Now, we have detected that TFTP doesn't work with the default KVM NAT configuration. You have to add support for it.
This document explain it:
Create the virtual machine in the Opengnsys console
We have to create the support configuration to this virtual PC in the Opengnsys console.
The virtual machine runs inside a NATed network, usually with a IP address. Then, these vms uses the Ravada server as gateway. We have to create an new classroom with the NAT configuration to allow opengnsys to assign correctly the network mask and the gateway. This is the ravada-classroom configuration:
.. image:: images/opengnsys_ravada_classroom.png
* gateway: (KVM NAT default gateway)
* netmask: (KVM NAT default netmask)
* IP multicast: your multicast group
* Menu: your page menu
* Repository: your image repository
Now, we have to create a computer inside your ravada classroom that is your virtual machine. Copy the MAC address of your empty machine:
.. prompt:: bash $
virsh net-dhcp-leases default
Expiry Time MAC address Protocol IP address Hostname Client ID or DUID
2018-11-27 09:11:39 52:54:00:a7:49:34 ipv4 - 01:52:54:00:a7:49:34
.. image:: images/opengnsys_computer.png
And now, re-generate the TFTPBOOT files:
.. image:: images/opengnsys_generate_tftpboot.png
In this example, we have assigned the new PC to the ``ogAdmin`` group.
Now, you can boot the empty machine:
We have detected that the new machine boots, but it hangs just when the menu had to appear. After debugging, we have detected that the virtual machine don't have access to the http server with the menus. This a problem with routing. We have resolved creating a fake computer with the IP and MAC address of the KVM external NAT:
.. prompt:: bash $
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet netmask broadcast
inet6 fe80::20a:f7ff:feba:c980 prefixlen 64 scopeid 0x20<link>
ether 00:0a:f7:ba:c9:80 txqueuelen 1000 (Ethernet)
RX packets 11251336 bytes 196755808380 (196.7 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11875794 bytes 4220061188 (4.2 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
.. image:: images/opengnsys_fake_computer.png
* IP: external NAT address of your RAVADA system
* MAC: external MAC address of your RAVADA system
This is our standard menu:
.. image:: images/opengnsys_menu.png
Now, you can boot your standard images in a virtual environment of Ravada. You have to be sure that your images have support to run in a virtualized system. In Linux images, the kernel have support ``/dev/vda`` devices. In Windows systems, you have to add the virtio drivers.
Special script adaptation
Our images boots ok, but our opengnsys instance doesn't detect the virtual disk. The problem was in our system, wich is very old (v1.0.5). To add support to detect `/dev/vda devices`, we have patched the ``/opt/opengnsys/client/lib/engine/bin/Disk.lib`` library:
.. prompt:: bash $
# Listar dispositivo para los discos duros (tipos: 3=hd, 8=sd 253=vda). inLab 2018
ALLDISKS=$(awk '($1==3 || $1==8 || $1==253) && $4!~/[0-9]/ {printf "/dev/%s ",$4}' /proc/partitions)
VOLGROUPS=$(vgs -a --noheadings 2>/dev/null | awk '{printf "/dev/%s ",$1}')
This patch adds vda disk detection to the ``ogDiskToDev`` function. (minor 253 -> vda devices). This problem was fixed in later versions.
.. Ravada VDI documentation
How to import a OpenGnsys image
Dani Sanchez - 28/Nov/2018
How to import a OpenGnsys image
First of all, copy the .img OpenGnsys image file to your Ravada system.
The .img OpenGnsys files are raw disk dump compressed with lzop. You can see the contents of a img lzop file with:
.. prompt:: bash $
lzop -l B5part3dataUbuntu.img
method compressed uncompr. ratio uncompressed_name
LZO1X-1 4536669058 7962881402 57.0% B5part3dataUbuntu.img.raw
Now, we will decompress the file. We have to force it because it doesn't have a .lzop extension:
.. prompt:: bash $
lzop -x -S .img /opt/opengnsys/images/B5part3dataUbuntu.img
4 drwxr-xr-x 2 root root 4096 Nov 27 12:49 .
12 drwxrwxr-x 13 root opengnsys 12288 Nov 27 12:48 ..
7776256 -rwxrwxr-x 1 opengnsys opengnsys 7962881402 Oct 26 12:51 B5part3dataUbuntu
As you can see, the raw file have no extension.
.. prompt:: bash $
file B5part3dataUbuntu
B5part3dataUbuntu: data
Now, we have the raw content of our image disk. Opengnsys uses partclone to create an image disk. The next step is dump this raw file to a qcow2 disk using partclone.
.. Tip:: You can get the partclone utilities from opengnsys, you can download from the web:, or extract from a partclone package for you linux distribution.
You can inspect the raw file with:
.. prompt:: bash $
./ ./B5part3dataUbuntu
Partclone v0.2.38
unknow mode
File system: EXTFS
Device size: 69.8 GB
Space in use: 69.7 GB
Free Space: 85.1 MB
Block size: 4096 Byte
Used block : 17008739
Now, we have to create an empty qcow2 file and dump the raw file inside. First of all, create the qcow2 file. It's important to check the size to ensure that the dump will fit in.
.. prompt:: bash $
qemu-img create -f qcow2 B5part3dataUbuntu.qcow2 70G
Now, we mount the qcow2 file in your system, to dump it.
.. Tip:: You can follow this guide to do it: `How to mount a qcow2 disk image <>'__
.. prompt:: bash $
qemu-nbd --connect=/dev/nbd0 ./B5part3dataUbuntu.qcow2
Now, whe can create the partition structure of your disk. After create it, this is the result:
.. prompt:: bash $
fdisk /dev/nbd0
Disk /dev/nbd0: 90 GiB, 96636764160 bytes, 188743680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc0545c3a
Device Boot Start End Sectors Size Id Type
/dev/nbd0p1 2048 182454271 182452224 87G 83 Linux
/dev/nbd0p2 182454272 188743679 6289408 3G 82 Linux swap / Solaris
Now, we have 2 partitions, ``/dev/nbd0p1`` and ``/dev/nbd0p2``. To dump the img disk we have to use the partclone.ext3 utility:
Command to restore:
.. prompt:: bash $
# ./partclone.ext3 -s ./B5part3dataUbuntu -O /dev/nbd0p1 -r
Partclone v0.2.38
Starting to restore image (./B5part3dataUbuntu) to device (/dev/nbd0p1)
Calculating bitmap... Please wait... done!
File system: EXTFS
Device size: 69.8 GB
Space in use: 69.7 GB
Free Space: 85.1 MB
Block size: 4096 Byte
Used block : 17008739
The process begin, and you can follow the logs:
.. prompt:: bash $
00:00:07, Remaining: 00:05:36, Completed: 2.04%, Rate: 12.16GB/min,
Elapsed 00:00:01, Completed: 99.97%, Rate: 1.23GB/min,
Elapsed: 00:56:28,
Remaining: 00:00:00, Completed: 99.98%, Rate: 1.23GB/min, Elapsed: 00:56:29,
Remaining: 00:00:00, Completed:100.00%, Rate: 1.23GB/min,
Elapsed: 00:56:29, Remaining: 00:00:00,
Completed:100.00%, Rate: 1.23GB/min,
Total Time: 00:56:29, Ave. Rate: 1.2GB/min, 100.00% completed!
Total Time: 00:56:29, Ave. Rate: 1.2GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully restored the image (./B5part3dataUbuntu) to the device (/dev/nbd0p1)
Cloned successfully.
root@willow: /ssd/estegoxCloneC6root@willow:/ssd/estegoxCloneC6#
Now, you can verify the filesystem, mounting it:
.. prompt:: bash $
mount /dev/nbd0p1 /mnt/suse
ls -als /mnt/suse/
total 168
4 drwxr-xr-x 26 root root 4096 Mar 2 12:20 .
4 drwxr-xr-x 4 root root 4096 Mar 1 13:55 ..
4 drwxr-xr-x 2 root root 4096 Feb 3 2017 assig
4 -rw------- 1 root root 199 Mar 2 11:42 .bash_history
4 drwxr-xr-x 2 root root 4096 Feb 2 11:51 bin
4 drwxr-xr-x 4 root root 4096 Mar 2 12:30 boot
4 drwxr-xr-x 3 root root 4096 May 10 2017 mnt
20 -rw-r--r-- 1 root root 19732 Sep 23 2015 ogAdmLnxClient.log
4 drwxr-xr-x 80 root root 4096 Feb 19 11:33 opt
Maybe didn't full the entire disk. You can expand it to fit all the disk:
.. prompt:: bash $
umount /mnt/suse
e2fsck /dev/nbd0p1
e2fsck 1.43.5 (04-Aug-2017)
/dev/nbd0p1: clean, 1897474/5701632 files, 16969078/22806528 blocks
resize2fs /dev/nbd0p1
Now, unmount que qcow2 file:
.. prompt:: bash $
qemu-nbd --disconnect /dev/nbd0
And that's all! Now you can create a Ravada vm and attach the disk.
It's possible that the system needs some extra adjustments. One tipical problem is modify the ``/etc/fstab`` to change the ``/dev/sda`` references to ``/dev/vda`` . Another common problem is recreate the grub boot or add support to ``/dev/vda`` devices.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment