adfinis / virtesk Goto Github PK

An Open Source VDI management solution to allow running virtual desktops in a RHEV/Ovirt environment seamlessly

License: GNU General Public License v3.0

Shell 7.77% Makefile 1.30% Python 90.92%

ovirt rhev vdi virtual-desktop python automation rollout

virtesk's Introduction

Virtesk-VDI

Virtesk-VDI is an Open Source VDI solution. It allows to run virtual desktops in a RHEV/Ovirt environment seamlessly. The virtual desktops are displayed on thin clients in physical rooms. You can manage both the virtual desktops and the physical thin clients efficiently using the well-aligned tool collection.

It is well-suited to virtualize workplaces in educational environments.

The technical building blocks are:

Red Hat Enterprise Virtualization (RHEV) / Ovirt Virtualization
Spice VDI protocol
RHEL / CentOS for infrastructure services
Fedora Linux for thin clients
Active Directory (or Samba4) for Windows domain services
Windows VDI desktops

Documentation is available here.

Features

Thin client user experience

Thin clients are very easy to use:

Turn thin client on
Login directly on virtual Windows desktop
Work
Turn thin client off

Features:

Virtual Windows desktop - feels like a native Windows desktop
USB redirect
Audio: headphones, loudspeakers, microphones
One single login - no need to enter credentials twice
Comfortable thin client devices - small and silent

Thin client administration

Virtesk-VDI features a fully automated network rollout of thin clients.

The following remote administration features for thin clients are available:

Remote control / remote scripting (Tool tc_ssh)
Screenshots (Tool tc_screenshot)
Unattended Upgrades / Re-Installations (Tool tc_rollout_kexec)

Virtual Rooms

Virtesk-VDI features virtual Windows desktops organized in virtual rooms.

Virtual rooms are useful for educational institutions - physical rooms are mapped to virtual rooms. This is useful when combined with 3rd party classroom management and monitoring software like iTalc, UCS@School, MasterEye, ...

Instant switching of virtual rooms is possible. For example, one set of VMs can be used for normal teaching, and a dedicated set of secure VMs can be assigned for exams.

The 1:1-mapping from thin clients to desktop VMs is controlled through a postgres database.

Application and desktop maintenance

A master VM (the "gold image") is used for application installation and desktop configuration. This master VM can then be cloned as often as necessary.

A set of tools (virtesk-virtroom-rollout and friends) helps to simplify and automate the necessary tasks. Scripting and automation features like automatic Windows domain join are available.

Nightly desktop reset

For situations where clearly-defined centrally managed workplaces are desired, the nightly desktop reset feature comes in handy:

A snapshot is created upon VM creation
Every night, the VMs is set back to snapshot state

This is useful to reduce time and effort spent by your IT support team: Desktops are always in a well defined state, divergence of desktops is avoided, and leftovers from old user sessions are cleaned up.

Requirements

Virtualization hardware (~ 4GB Ram per workplace), shared storage attached through iscsi or FibreChannel
RHEV/oVirt 3.5.x
Active Directory (or Samba 4) for Windows domain features
A supported OS for virtual Desktops ( stable: Windows 7; Windows 10 support is underway)
Thin clients: Any linux compatible (x86 or x86_64, must be supported by Fedora Linux) hardware can be used. Usually, small, silent and low power thin client devices are used; However, it is also possible to re-use old desktop computers as thin clients
Infrastructure server VM (part of Virtesk-VDI)

Bird's eye view of operation / installation

The steps to introduce Virtesk-VDI are more or less:

Preparing RHEV/Ovirt for VDI operation
Thin clients: Seting up Virtesk-VDI infrastructure services, including a Fedora Linux mirror, a network rollout infrastructure, scripts for unattended Fedora installations based on Kickstart, and a postgres database for VM-to-thin-client-mapping.
Installing virtesk-tc-tools for thin client remote management
Installing a Windows 7 master VM ("gold image")
Setting up the Windows unattended setup process for VM creation and for automatic Windows domain join
Setting up virtesk-virtroom-tools for virtual room management
Creating a network concept, including naming standards and ip-address conventions

virtesk's People

Contributors

Stargazers

Watchers

virtesk's Issues

Hostname and IP recognition fails

On a new install on Fedora 25, connect_spice crashes, because it tries to read the dhclient leasefile which it doesn't have any permission anymore.

This functionality can be found in the file find_thinclient_identifier.py in the functions

find_dhclient_leasefiles()
extract_identifiers_from_leasefiles(leasefilepaths)

Proposal: Instead of dhclient leasefile use the nmcli which can read the infos through the network manager.

Example output, unfortunately without DHCP hostname

nmcli device show
GENERAL.GERÄT: eth0
GENERAL.TYP: ethernet
GENERAL.HWADDR: D8:CB:8A:64:37:1B
GENERAL.MTU: 1500
GENERAL.STATUS: 100 (verbunden)
GENERAL.VERBINDUNG: eth0
GENERAL.CON-PFAD: /org/freedesktop/NetworkManager/ActiveConnection/0
WIRED-PROPERTIES.TRÄGERFREQUENZ: an
IP4.ADRESSE1: 10.1.5.212/16
IP4.GATEWAY: 10.1.1.1
IP4.DNS1: 10.1.2.8
IP4.DNS2: 10.1.2.22
IP4.DNS3: 10.9.2.1
IP4.DOMAIN1: sygroup-int.ch
IP6.ADRESSE1: 2001:618:1:105:dacb:8aff:fe64:371b/64
IP6.ADRESSE2: fe80::dacb:8aff:fe64:371b/64
IP6.GATEWAY: fe80::200:5eff:fe00:140
IP6.ROUTE1: dst = 2001:618:1:105::/64, nh = ::, mt = 100

GENERAL.GERÄT: lo
GENERAL.TYP: loopback
GENERAL.HWADDR: 00:00:00:00:00:00
GENERAL.MTU: 65536
GENERAL.STATUS: 10 (nicht verwaltet)
GENERAL.VERBINDUNG: --
GENERAL.CON-PFAD: --
IP4.ADRESSE1: 127.0.0.1/8
IP4.GATEWAY: 
IP6.ADRESSE1: ::1/128
IP6.GATEWAY: 
@

The new function should read the IPV4.ADRESSE[x] (seems to be locale dependent) and ipv4.dhcp-hostname.

Must be tested on Fedora 22!

Error handling on resolution change

When xrandr fails due to an error (e.g. non supported resolution or garbage in the database field), the error should be logged and the connection should proceed without changing the resolution.

2016-12-19 12:59:32,837 - ERROR - Command '['/usr/bin/xrandr', '-s', '1280x1024']' returned non-zero exit status 1 Traceback (most recent call last): File "/opt/virtesk-tc-connectspice/connect_spice_client.py", line 697, in error_handling_loop self.main_action_sequence() File "/opt/virtesk-tc-connectspice/connect_spice_client.py", line 649, in main_action_sequence self.change_resolution() File "/opt/virtesk-tc-connectspice/connect_spice_client.py", line 280, in change_resolution subprocess.check_output(shlex.split(xrandr_command)) File "/usr/lib64/python2.7/subprocess.py", line 574, in check_output raise CalledProcessError(retcode, cmd, output=output) CalledProcessError: Command '['/usr/bin/xrandr', '-s', '1280x1024']' returned non-zero exit status 1

Reference to RepoForge/RPMForge

In the documentation (DocLink: Virtesk Infrastructure Server), there is a reference to RPMForge.
This project is dead and not maintained anymore and the reference should be removed.

Example Database Layout inconsistent

The example database layout in the folder sample_config is faulty.
connect_spice_client.py uses the view thinclient_everything to find the mapping between Thinclient and VM.

The schema in database-layout.sql is under PostgreSQL 9.2.16 (CentOS 7.2) faulty. Creation of the DB does not work.

-bash-4.2$ psql --single-transaction vdi < database-layout.sql 
CREATE TABLE
CREATE VIEW
CREATE VIEW
CREATE TABLE
CREATE TABLE
CREATE VIEW
ERROR: syntax error at or near "ON" 
LINE 16: current_thinclient_to_vm_mapping c ON (((s.thinclien...
^
CREATE SEQUENCE
ALTER TABLE
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "dhcphostname_to_thinclient_mapping_pkey" for table "dhcphostname_to_thinclient_mapping" 
ALTER TABLE
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "systemuuid_to_thinclient_mapping_pkey" for table "systemuuid_to_thinclient_mapping" 
ALTER TABLE
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "timed_thinclient_to_vm_mapping_pkey" for table "timed_thinclient_to_vm_mapping" 
ALTER TABLE

As a fix, you can use this SQL query:

CREATE VIEW thinclient_everything_view AS
SELECT DISTINCT s.thinclient, c.vm, s.dhcp_hostname, 
upper(s.systemuuid::text)::character varying AS systemuuid, c.id, 
c.start_date, c.end_date, c.prio, c.shutdown_vm
FROM sysinfo_to_thinclient_mapping s
LEFT JOIN current_thinclient_to_vm_mapping c ON s.thinclient::text = c.thinclient::text
ORDER BY c.prio DESC, c.start_date, c.id;

In addition, there is a database-layout-update-001.sql, which removes this view but does not recreate it. I'm guessing that the SQL statement
CREATE VIEW thinclient_everything_view AS is missing. But it also fails with the same error message when executed.

Document known Workarounds for GPU issues with kexec

We've have encountered a setup with a set of systems when running on Fedora 25-based terminal clients (Linux kernel 4.8.5) who have shown partial hang during rollout in graphical mode of the Anaconda install. This issue could be reliably worked around by forcing Anaconda into text mode.

Another problem resulting in reliable kernel panic on a certain hardware model could be worked around by forcing kexec into realmode (déjà-vu?).

These issues have not existed so far on Fedora 22 but have appeared on Fedora 25 and Kernel 4.8.5. Since both cases are pretty specific to a set of hardware, distribution release and kernel version, I'd propose to document the workarounds.

I'll reference a pull request, but I'd like to discuss if that is the preferred way for upstream.

make release
rm -f *.pyc
tar --transform 's,^,amoothei-tc-connectspice/,S' -czf /var/www/mirror/private/thinclients/thinclient-software/connect_spice_client-new.tar.gz *.py amoothei-tc-connectspice-shutdown-vm amoothei-tc-connectspice-main
tar: amoothei-tc-connectspice-shutdown-vm: Cannot stat: No such file or directory
tar: amoothei-tc-connectspice-main: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
make: *** [release] Error 2

A grep from the virtesk-tc-connectspice

grep -ri amoothei *
connect_spice_client.py:# This file is part of Amoothei-VDI.
connect_spice_client.py:# Amoothei-VDI is free software: you can redistribute it and/or modify
connect_spice_client.py:# Amoothei-VDI is distributed in the hope that it will be useful,
connect_spice_client.py:# along with Amoothei-VDI.  If not, see <http://www.gnu.org/licenses/>.
find_thinclient_identifier.py:# This file is part of Amoothei-VDI.
find_thinclient_identifier.py:# Amoothei-VDI is free software: you can redistribute it and/or modify
find_thinclient_identifier.py:# Amoothei-VDI is distributed in the hope that it will be useful,
find_thinclient_identifier.py:# along with Amoothei-VDI.  If not, see <http://www.gnu.org/licenses/>.
Makefile:    tar --transform 's,^,amoothei-tc-connectspice/,S' -czf /var/www/mirror/private/thinclients/thinclient-software/connect_spice_client-new.tar.gz *.py amoothei-tc-connectspice-shutdown-vm amoothei-tc-connectspice-main
Makefile:    flake8 --doctests -j auto --ignore=E221,E222,E251,E272,E241,E203 *.py amoothei-tc-connectspice-*
Makefile:    flake8 --doctests -j auto *.py amoothei-tc-connectspice-*
spice_xpi_controller.py:# This file is part of Amoothei-VDI.
spice_xpi_controller.py:# Amoothei-VDI is free software: you can redistribute it and/or modify
spice_xpi_controller.py:# Amoothei-VDI is distributed in the hope that it will be useful,
spice_xpi_controller.py:# along with Amoothei-VDI.  If not, see <http://www.gnu.org/licenses/>.
virtesk-tc-connectspice-main:# This file is part of Amoothei-VDI.
virtesk-tc-connectspice-main:# Amoothei-VDI is free software: you can redistribute it and/or modify
virtesk-tc-connectspice-main:# Amoothei-VDI is distributed in the hope that it will be useful,
virtesk-tc-connectspice-main:# along with Amoothei-VDI.  If not, see <http://www.gnu.org/licenses/>.
virtesk-tc-connectspice-shutdown-vm:# This file is part of Amoothei-VDI.
virtesk-tc-connectspice-shutdown-vm:# Amoothei-VDI is free software: you can redistribute it and/or modify
virtesk-tc-connectspice-shutdown-vm:# Amoothei-VDI is distributed in the hope that it will be useful,
virtesk-tc-connectspice-shutdown-vm:# along with Amoothei-VDI.  If not, see <http://www.gnu.org/licenses/>.