OpenSource Citrix XenServer - VDR als Server in VM inkl. DVB Karten

Hi,

nachdem Citrix seinen XenServer (6.2) inkl. des XenCenter, Management für Windows, OpenSource gestellt hatte, machte mich das natürlich neugierig. Ganz besonders ob man auch damit ohne entsprechende (VT-d) CPU DVB Karten an PVs virtualisieren kann. Vorab, ja man kann, spräche also nix dagegen es mal mit einer yaVDR Headless Installation zu probieren.

Dank XenCenter ist die Lösung recht komfortabel, bietet eine Übersicht über Memory und CPU Auslastung, Snapshot-Funktion u.a., also alles in allem etwas komfortabler als mein "Ubuntu Precise 12.04 goes Xen Hypervisor" Ansatz. Für einige Dinge muß man sich dennoch per SSH am XenServer anmelden, ISO-Store, pciback.

Die Maschinen werden aus dem XenCenter mittels sog. Templates installiert, Linux generell als "Pure Virtual" kurz PV, entweder vom ISO oder via Netzwerk als Bootstrap Installation, Windows immer als HVM, dazu werden XenTools inkl. Treiber mitgeliefert.

Auch hier der Hinweis, ich weiß auch hier nicht alles, habe zum ersten mal so richtig mit Citrix XenServer gearbeitet, mal sehen was sich so ergibt. Würde hier im ersten Post nur mal anreißen was ich grad habe, ein paar Screenshots und in den nächsten Tagen dann in einzelnen Posts einzelne Schritte ansprechen.

Mein derzeitige Testnudel wurde ja nach dem "Zotac GT630" Review wieder frei:

• Intel DH77EB, Celeron G540, 2x2GB, 1x2TB WD Red, 1x L4M Twin S2 V5.4 (hierfür eingebaut), BeQuiet L7 300W, 28W wie hier installiert => Jetzt auf Ziel-HW, s.Sig.
• Xen Default Installation von USB Stick, unter Windows am Besten mit "Universal USB Installer" erstellen.
• Anlegen eines lokalen ISO Stores, dazu später mehr
• Installation einer HVM mit "Windows Server 2012 Essentials R2"
• Bootstrap Installation aus dem Internet von "Ubuntu LTS Server 12.04" mit anschließender Virtualisierung der L4M DVB Karte

Kapitel:

• Besonderheiten Installation XenServer und Patches, diese kann man bei der OS Variante nicht aus dem XenCenter installieren
• Anlegen eines lokalen ISO Stores, Xen sieht nur einen im Netzwerk vor
• Installation Windows Server
  => angepasst zum Thema Verhältnis VCPU & Cores pro Socket
• Installation Ubuntu Server [LTS] aus dem Internet
• Virtualisierung der L4M Twin S2
• Erweiterung der Templates für "Arch Linux"
• Erweiterung der Templates für "Ubuntu Raring Ringtail 13.04"
• Erweiterung der Templates für "Ubuntu Saucy Salamander 13.10 (experimental)"
• Script zum löschen von Installations Templates
• Erweiterung der Templates für "Debian Jessie (testing)
• Umschalten von Bridge auf Open vSwitch
• USB Storage für Backup-Zwecke nativ an VMs durchreichen
• Durchsatz XenServer Windows HVM & Ubuntu PV
• Kontrolle des XenServers per Smartphone
• Windows Server 2003 Template als universaler Ausgangspunkt für HVMs
• Geräte via USB-over-Network - Server
• Geräte via USB-over-Network - Client
• etc.

Merker:

• Generator für Mac Adressen: http://justynshull.com/projects/random-mac-generator/
• Für Linux PVs: OS Boot Parameters "-- quiet pci=nomsi iommu=soft swiotlb=force irqpoll console=hvc0"
  => kann man bei Debian & Ubuntu direkt beim Anlegen der VM vergeben.
• Ubuntu Installations URL: http://archive.ubuntu.com/ubuntu/
• Debian Installations URL: http://ftp.de.debian.org/debian/
• Citrix Knowledgebase Artikel zu hp System Tools unter Xen (älter): http://support.citrix.com/article/CTX116367
• hp Software Delivery Repository: http://downloads.linux.hp.com/
• hp SDR Repository Listing: http://downloads.linux.hp.com/SDR/downloads/MCP/
  => Citrix XenServer basiert auf RHEL4 und ist eine i386/i686 Installation, nicht amd64, Pakete passend wählen.
  => VMs können sowohl i386 als auch amd64 sein.
• Für Desktop HVMs (Windows & Linux) das Template "Windows Server 2003", 32- oder 64-bit als Basis nehmen
  => das Template bietet alles was man benötigt und es zwingt einem nicht min 2048MB Hauptspeicher für die VM auf, sondern ab 512MB+
• XenServers Kernel 2.6.32 unterstützt perfekt aktuelle CPU Architekturen mit allen Features
  => u.a. SandyBridge, IvyBridge, seit 6.2 auch AMD Piledriver & Intel Haswell-DT
  => http://hcl.xensource.com/CPUMatrix.aspx
  => http://support.citrix.com/article/CTX137826
• Der Hypervisor von XenServer ist 64-bit und benötigt 64-bit fähige Hardware! Die Domain 0 ist aber eine 32-bit VM, siehe:
  => http://blogs.citrix.com/2011/0…er-domain-0-32-or-64-bit/
• USB-over-Network: http://www.usb-server.com/usb-server.html
• [size='8']Hotfixes for XenServer 6.2.0
• Nvidia Grid for VGPU Passthru with XenServer 6.2.0

Regards
fnu

Bei der Installation des XenServers habe ich eigentlich nichts großartig besonderes gemacht. Es werden drei verschiedene Arten zur Auswahl gestellt, deren Unterschied sich mir nicht ergibt, daher einfach Standard:

• Wie gesagt USB Stick unter Windows mit "Universal USB Installer" erstellen lassen, unetbootin sucks
• Die Storage Auswahl war bei mir einfach, nimm die ganze, die einzige Festplatte, es muß sich aber jeder selbst drüber klar werden wie er es haben möchte
• Beim Punkt IP Adresse und Hostname, alles fest definieren, ein Hypervisor der seine IP per DHCP bekommt finde ich falsch. Xen will einen FQDN, hinter einer ungepatchten Fritz!Box ist das [NAME].fritz.box
• Nach ein paar Minuten ist Installation beendet und XenServer meldet sich mit einem schicken Bootsplash und am Ende mit einer Service Console
• XenCenter installieren und verbinden

Patches können bei der OS Variante nicht aus dem XenCenter installiert werden. Da nach dem ersten Verbinden mit XenCenter direkt zwei Patches gelistet werden, installieren wir diese direkt:

• Hotfixes for XenServer 6.2.0
• XS62E001
• XS62E002
• XS62E003 => Kein Patch, sondern ein neue Version vom XenCenter.
• XS62E004
• XS62E005
• XS62E009
• XS62E010
• XS62E011
• XS62E012
• XenServer 6.2.0 Service Pack 1 => enthält alle vorhergenannten Hotfixes, Release Notes lesen!
• XS62ESP1001 => XenCenter für XenServer 6.2.0 SP1

Auf der jeweiligen URL gibt es den Download sowie die Installtionsanleitung per CommandLine auf dem XenServer, ganz unten im Dokument. Im Groben, ZIP auspacken, *.xsupdate auf den XenServer kopieren (ftp|sftp) und mit dem cmdline tool "xe" installieren.

Regards
fnu

Um sinnvoll VMs zu installieren, benötigt man natürlich Installationsmedien, aber wer will schon mit CDs oder DVDs hantieren, besser also ISO Images.

Leider sieht die Citrix Logik nur ein ISO Store im Netzwerk vor aber mit ein paar einfach Befehlen legt man sich den lokal an.

Per SSH auf den XenServer:

Zitat

#/> vgdisplay|grep "VG Name"
#/> lvcreate -L64G -n iso_storage [Name der Volumegruppe der eben zurück kam]
#/> mkfs -t ext3 -T largefiles4 /dev/[Name der Volumegruppe der eben zurück kam]/iso_storage
#/> mkdir /mnt/isoImages
#/> vi /etc/rc.local => nicht in die "/etc/fstab" eintragen, funktioniert nicht!
...
# Mount ISO store
ISO=/dev/[Name der Volumegruppe der eben zurück kam]/iso_storage
lvchange -a y $ISO
mount $ISO /mnt/isoImages
...
#/> mount /dev/[Name der Volumegruppe der eben zurück kam]/iso_storage /mnt/isoImages
#/> xe-mount-iso-sr /mnt/isoImages -o bind

Alles anzeigen

Nun erscheint sofort der neue ISO Store persistent im XenCenter, ISO Images werden per [sftp] nach "XenServer:/mnt/isoImages" kopiert und stehen ohne weiteres zutun im XenCenter zur Verfügung.

Regards
fnu

Sinn und Zweck eines Hypervisors ist es verschiedenste Betriebssystem auf ein Blech zu betreiben. Viele werden Windows Desktops in der Familie haben, daher installiere ich mal als Beispiel den "Windows Home Server" Nachfolger "Windows Server 2012 Essentials", hier in der Ausprägung "R2", analog zu Windows 8.1, das es als Preview zum Test gibt. WS2012 ist btw. sehr schnell auf Blech, daher auch sehr flott in einer VM.

• Im XenCenter rechte Maustaste auf den XenServer "New VM"
• Name vergeben, hier "w2012r2ess"
• Das Installationsmedium auswählen, hier erscheint das eben nach "XenServer:/mnt/isoImages" kopierte ISO Image
• VCPU:2, Memory:2048MB, was Default aus dem Installations-Template ist
• Storage ist aus dem Template 24GB default, viel zu wenig, also anpassen, hier 1024GB. Achtung der "." ist kein Tausender-Trenner sondern Komma
• Zusammenfassung und die Wahl ob man die VM automatisch starten lassen möchte.
  =>Dieser Punkt kann später nur per cmdline verändert werden, leider nicht aus dem XenCenter, soweit ich sehe.
• Speichern, Maschine startet automatisch oder muß per Mausklick angeschubst werden
• Die folgenden Screens abnicken
• Benutzer definierte Installation
• Key eintragen
• Plattenlayout festlegen, hier 60GB für "C:\", Rest wird "D:\"
• Installation laufen lassen, Maschine bootet ein paar Mal und fragt dann nach einen Administrator Passwort, definieren
• Am ersten Login Screen anmelden und direkt auf die Desktop Kachel klicken
• Nun konfiguriert sich der Server, die folgenden Fragen beantworten
• z.B.: Company Name: Familie XXX, Domäne: myXXX, Servername: higgins
• Name des Administrators: master, PWD vergeben
• Updateeinstellungen: "Empfohlene Einstellungen"
• "Konfigurieren" klicken, das dauert nun ein paar Minuten und man endet als "master" auf dem Desktop
• Den Desktop passend konfigurieren, z.B. Desktop als Start festlegen
• Jetzt die "xs-tools.iso" in das virtuelle DVD Laufwerk einlegen, im Desktop auf die "Bubble" klicken und die XenTools installieren
• Reboot
• Wieder als "master" anmelden, xs-tools.iso auswerfen, Dashboard aufrufen, die Konfigurationswizards duchgehen
• Anschliessend rechts oben im Dashboard "Einstellungen" anklicken, "Updates änder/installieren" und die neuesten Patches installieren lassen

[EDIT]
Windows Server 2012 [R2] Essential ist auf 2 CPU Sockets beschränkt, wie Standard und alle Desktop, was in den meisten Fällen kein großes Problem ist. Leider sind per Default alle VCPUs bei Xen 1 Core pro 1 Socket. Wenn man also 4 VCPUs definiert, sieht man diese zwar im "Geräte Manager", aber der Server nutzt nur 2 aktiv, eben 2 Sockets mit je einem Core. Daher per SSH auf den XenServer:

#/> xe vm-list name-label=w2012r2ess params=uuid --minimal => Find out UUID
#/> xe vm-param-set platform:cores-per-socket=2 uuid=[UUID] => not set equals to 1 core per socket, raise it to 2, 4, 6, 8 to meet your requirements
#/> xe vm-list name-label=w2012r2ess params=platform => Check parameter
#/> xe vm-reboot name-label=w2012r2ess

Dieses Vorgehen gilt im Prinzip für alle relevanten Windows Versionen, HomeServer, Standard, Essential, Windows 7 & 8 ...
[/EDIT]

Ab hier kann man den Server mit der Console im XenCenter administrieren oder besser per RDP Session.

Regards
fnu

Als nächste Funktion der VDR Server, hier basierend auf Ubuntu LTS Server 12.04.

• Im XenCenter rechte Maustaste auf den XenServer "NewVM"
• Template Ubuntu Precise Pangolin 12.04 (64-bit)
• Name vergeben, hier: vdrserv
• Install from URL: "http://archive.ubuntu.com/ubuntu/"
• VCPU: 1, Memory: 256MB default
• Storage, erstmal 16GB als "/"
• Maschine startet, Console zeigt den Debian Installer
• "C", Europe, Germany
• hostname: vdrserv, Archive Mirror: Germany
• Proxy wenn benötigt
• User: vdr, PWD definieren
• Timezone: Europe/Berlin
• Use entire disk
• Nun folgt die Basis Installation
• Automatic Updates oder auch nicht
• Tasksel Auswahl: Basic Ubuntu Server & OpenSSH Server
• grub in den Master Boot Record installieren
• System Clock ist hier nicht UTC, weil das System der Hypervisor ist
• Nach einigen Minuten ist Installation fertig und Ihr könnte Eure persönlich Anpassungen per XenCenter Console oder SSH durchführen

Eine wichtige Aktion ist die Installation der xen_tools, damit dieser Server wie jeder andere auch sauber überwacht wird und aus dem XenCenter gestartet und gestoppt werden kann. Im XenCenter "xs-tools.iso" an das DVD der Maschine binden:

#/> sudo mount /dev/xvdd /mnt
#/> sudo dpkg -i /mnt/Linux/xe-guest-utilities_6.2.0-1120_amd64.deb
#/> umount /mnt
#/> sudo reboot

"xs-tools.iso" wieder trennen ...

Regards
fnu

Nun benötigen wir noch DVB Karten in unserem VDR Server, also per SSH auf den XenServer:

Zitat

#/> lspci
...
02:00.0 Multimedia controller: Digital Devices GmbH Octopus LE DVB adapter
03:00.0 Multimedia video controller: Micronas Semiconductor Holding AG nGene PCI-Express Multimedia Controller (rev 01)
...
#/> /opt/xensource/libexec/xen-cmdline --set-dom0 "pciback.permissive pciback.hide=(02:00.0)(03:00.0)"
...
#/> extlinux /boot --update
#/> reboot

Alles anzeigen

Anschließend pimpen wir die eben installierten VM(s), die Boot-Parameter kann man auch schon beim Anlegen für die Netzwerk-Installation angeben, im Feld "Advanced OS boot parameters":

Zitat

#/> sudo apt-get install linux-generic-lts-raring linux-headers-generic-lts-raring linux-tools-lts-raring linux-firmware-nonfree wajig htop atop vim deborphan
#/> sudo vi /etc/default/grub => wenn nötig anpassen!
...
GRUB_CMDLINE_LINUX="pci=nomsi iommu=soft swiotlb=force irqpoll console=hvc0"
...
#/> sudo update-grub
#/> sudo shutdown -h now

Alles anzeigen

Nun wieder per SSH auf den XenServer:

#/> dmesg|grep pciback
...
[    1.636843] Kernel command line: root=LABEL=root-ffgntzgl ro xencons=hvc console=hvc0 console=tty0 quiet vga=785 splash pciback.permissive pciback.hide=(02:00.0)(03:00.0)
[    1.932541] pciback 0000:02:00.0: seizing device[    1.932552] pciback 0000:03:00.0: seizing device
[    5.033788] pciback 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    5.033797] pciback 0000:03:00.0: PCI INT A disabled
[    5.034572] pciback 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    5.034580] pciback 0000:02:00.0: PCI INT A disabled
...
#/> xe vm-list => wir benötigen die UUID(s) der Ziel-VMs
#/> xe vm-param-set other-config:pci=0/0000:02:00.0 uuid=[Hier die UUID der ersten VM]
#/> xe vm-param-set other-config:pci=0/0000:03:00.0 uuid=[Hier die UUID der zweiten VM]

VM wieder starten, einloggen, dann sollte das so aussehen:

#/> uname -a
...
Linux vdrserv 3.8.0-26-generic #38~precise2-Ubuntu SMP Thu Jun 20 18:29:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
...
#/> lspci
...
00:00.0 Multimedia controller: Digital Devices GmbH Octopus LE DVB adapter
...
#/> dmesg | grep -i ddbridge
...
[   11.506620] DDBridge 0000:00:00.0: enabling device (0000 -> 0002)
[   11.506775] DDBridge 0000:00:00.0: Xen PCI mapped GSI16 to IRQ35
[   11.506792] DDBridge driver detected: Digital Devices Cine S2 V6 DVB adapter
[   11.510409] DVB: registering new adapter (DDBridge)
[   11.931456] DDBridge 0000:00:00.0: DVB: registering adapter 0 frontend 0 (STV090x Multistandard)
...
[   11.931608] DVB: registering new adapter (DDBridge)
[   11.968447] DDBridge 0000:00:00.0: DVB: registering adapter 1 frontend 0 (STV090x Multistandard)
...
...
#/> ll /dev/dvb/adapter*
/dev/dvb/adapter0:total 0
drwxr-xr-x 2 root root     120 Jul 29 10:37 ./
drwxr-xr-x 4 root root      80 Jul 29 10:37 ../
crw-rw---- 1 root video 212, 1 Jul 29 10:37 demux0
crw-rw---- 1 root video 212, 2 Jul 29 10:37 dvr0
crw-rw---- 1 root video 212, 0 Jul 29 10:37 frontend0
crw-rw---- 1 root video 212, 3 Jul 29 10:37 net0
/dev/dvb/adapter1:total 0
drwxr-xr-x 2 root root     120 Jul 29 10:37 ./
drwxr-xr-x 4 root root      80 Jul 29 10:37 ../
crw-rw---- 1 root video 212, 5 Jul 29 10:37 demux0
crw-rw---- 1 root video 212, 6 Jul 29 10:37 dvr0
crw-rw---- 1 root video 212, 4 Jul 29 10:37 frontend0
crw-rw---- 1 root video 212, 7 Jul 29 10:37 net0

#/> uname -a
...
Linux saucy 3.10.0-6-generic #17-Ubuntu SMP Fri Jul 26 18:29:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
...
#/> lspci
...
00:00.0 Multimedia video controller: Micronas Semiconductor Holding AG nGene PCI-Express Multimedia Controller (rev 01)
...
#/> dmesg|grep -i ngene
[    6.305817] nGene PCIE bridge driver, Copyright (C) 2005-2007 Micronas
[    6.305888] ngene 0000:00:00.0: enabling device (0000 -> 0002)
[    6.305964] ngene 0000:00:00.0: Xen PCI mapped GSI18 to IRQ36
[    6.305972] ngene: Found Digital Devices DuoFlex PCIe or miniPCIe
[    6.307608] ngene: Device version 1
[    6.380768] ngene: Loading firmware file ngene_18.fw.

Zur Erinnerung, alles mit CPU die kein IOMMU/VT-d beherrscht.

Regards
fnu

Nun decken die Installations Templates nicht alles ab was der gemeine VDR'ler evtl. so benötigt. Daher bin ich mal auf die Suche gegangen für "Arch Linux", was ja auch einige betreiben und weil es zu den schwierigen Aufgaben gehört.

So gut Arch im Betrieb ist, ich mag es, vorallem pacman, so sch... finde ich persönlich die Installation. Das konnte Debian & Slackware in den 1990er Jahren schon besser und ist nicht wirklich gut Netzwerk-tauglich ...

Nun denn, melden wir uns als "root" per SSH am XenServer an:

Zitat

#/> mkdir templates
#/> cd templates
#/> vi arch_x86_64.sh
...
#!/bin/sh
baseUUID=$(xe template-list name-label="Ubuntu Maverick Meerkat 10.10 (64-bit) (experimental)" --minimal)
newUUID=$(xe vm-clone uuid=$baseUUID new-name-label="Arch Linux (64-bit)")
xe template-param-set uuid=$newUUID \
name-description="Template that allows VM installation of Arch Linux." \
other-config:install-distro=pygrub \
other-config:install-methods=http,ftp \
other-config:install-repository=http://mirrors.kernel.org/archlinux/iso/latest/arch/boot/x86_64/ \
other-config:install-kernel=vmlinuz \
other-config:install-ramdisk=archiso.img \
PV-args="-- archiso_http_srv=http://mirrors.kernel.org/archlinux/iso/latest/ archisobasedir=arch checksum=y ip=dhcp console=hvc0" \
other-config:default_template=false
xe template-param-remove uuid=$newUUID \
param-name=other-config param-key=debian-release
xe template-list uuid=$newUUID
...
#/> vi arch_i686.sh
...
#!/bin/sh
baseUUID=$(xe template-list name-label="Ubuntu Maverick Meerkat 10.10 (32-bit) (experimental)" --minimal)
newUUID=$(xe vm-clone uuid=$baseUUID new-name-label="Arch Linux (32-bit)")
xe template-param-set uuid=$newUUID \
name-description="Template that allows VM installation of Arch Linux." \
other-config:install-distro=pygrub \
other-config:install-methods=http,ftp \
other-config:install-repository=http://mirrors.kernel.org/archlinux/iso/latest/arch/boot/i686/ \
other-config:install-kernel=vmlinuz \
other-config:install-ramdisk=archiso.img \
PV-args="-- archiso_http_srv=http://mirrors.kernel.org/archlinux/iso/latest/ archisobasedir=arch checksum=y ip=dhcp console=hvc0" \
other-config:default_template=false
xe template-param-remove uuid=$newUUID \
param-name=other-config param-key=debian-release
xe template-list uuid=$newUUID
...
#/> sh arch_x86_64.sh
#/> sh arch_i686.sh

Alles anzeigen

Nun finden sich zwei neue Templates zum Anlegen von VMs.

Die Installation findet aus einem Arch Linux im RAM-FS statt, das wird hier komplett aus dem Internet gezogen und benötigt mehr Speicher als die Default 256MB, mit 384MB läuft die Installation aber.

Regards
fnu

So, weiter geht die Lucy, habe mich von meinem Test-Server verabschiedet und meinen Haupt-Server auf XenServer umgestellt.

Um den letzten Ubuntu Stand, 13.04 als PV aus dem Netz zu installieren, legen wir weitere Templates an:

Zitat

#/> cd templates
#/> vi ubuntu_raring_amd64.sh
...
#!/bin/sh
baseUUID=$(xe template-list name-label="Ubuntu Precise Pangolin 12.04 (64-bit)" --minimal)
newUUID=$(xe vm-clone uuid=$baseUUID new-name-label="Ubuntu Raring Ringtail 13.04 (64-bit)")
xe template-param-set uuid=$newUUID \
other-config:default_template=true \
other-config:debian-release=raring
xe template-list uuid=$newUUID
...
#/> vi ubuntu_raring_i386.sh
...
#!/bin/sh
baseUUID=$(xe template-list name-label="Ubuntu Precise Pangolin 12.04 (32-bit)" --minimal)
newUUID=$(xe vm-clone uuid=$baseUUID new-name-label="Ubuntu Raring Ringtail 13.04 (32-bit)")
xe template-param-set uuid=$newUUID \
other-config:default_template=true \
other-config:debian-release=raring
xe template-list uuid=$newUUID
...
#/> sh ubuntu_raring_amd64.sh
#/> sh ubuntu_raring_i386.sh

Alles anzeigen

Nun finden sich wieder vordefinierte Installations-Templates für "Ubuntu Raring Ringtail 13.04"

Regards
fnu

Und noch Templates für den kommenden Release "Ubuntu Saucy Salamander 13.10":

Zitat

#/> cd templates
#/> vi ubuntu_saucy_amd64.sh
...
#!/bin/sh
baseUUID=$(xe template-list name-label="Ubuntu Precise Pangolin 12.04 (64-bit)" --minimal)
newUUID=$(xe vm-clone uuid=$baseUUID new-name-label="Ubuntu Saucy Salamander 13.10 (64-bit)")
xe template-param-set uuid=$newUUID \
other-config:default_template=true \
other-config:debian-release=saucy
xe template-list uuid=$newUUID
...
#/> vi ubuntu_saucy_i386.sh
...
#!/bin/sh
baseUUID=$(xe template-list name-label="Ubuntu Precise Pangolin 12.04 (32-bit)" --minimal)
newUUID=$(xe vm-clone uuid=$baseUUID new-name-label="Ubuntu Saucy Salamander 13.10 (32-bit)")
xe template-param-set uuid=$newUUID \
other-config:default_template=true \
other-config:debian-release=saucy
xe template-list uuid=$newUUID
...
#/> sh ubuntu_saucy_amd64.sh
#/> sh ubuntu_saucy_i386.sh

Alles anzeigen

Regards
fnu

Falls mal was schiefläuft beim Anlegen der Templates, kann man diesen auch wieder eliminieren.

Dieser kleine Helfer aus dem WWW erleichtert das:

Zitat

#/> cd templates
#/> vi xe-remove-template.sh
...
#!/bin/bash
## xe-remove-template.sh, remove template by name on local xenserver instance
## Author: Michael Bieri <mb@alonso.ch>
## Warning: This script has no brain - use your own!

UUID=$(xe template-list name-label="$1" --minimal)

if [[ -z $UUID ]] ; then
echo "Sorry - Template not found"
echo "Usage: $0 <template-name>"
exit 1
fi

echo "using UUID: $UUID"

xe template-param-remove uuid=$UUID param-name=other-config param-key=default_template
xe template-uninstall template-uuid=$UUID force=true

echo "Done"
...
#/> Usage: sh xe-remove-template.sh "template-name"

Alles anzeigen

also z.B.:

"sh xe-remove-template.sh "Ubuntu Saucy Salamander 13.10 (64-bit)(experimental)"

Regards
fnu

ranseyer

Der Sinn und Zweck dieses Threads ist nicht irgendjemandem was anzupreissen oder gar zu verkaufen, nur eine Dokumentation als Leitfaden. Eine Antwort würde vmtl. auch recht lang werden und ganz sicher wieder ein Kontroverse lostreten, dazu habe ich aber hier jetzt keine Lust, in einem anderen, eigenen Thread gerne ...

@all

Hier schon mal Templates für "Debian Jessie". Aber da gibt es noch keinen (!) Network Installer, also etwas Geduld:

Zitat

#/> cd templates
#/> vi debian_jessie_amd64.sh
...
#!/bin/sh
baseUUID=$(xe template-list name-label="Debian Wheezy 7.0 (64-bit)" --minimal)
newUUID=$(xe vm-clone uuid=$baseUUID new-name-label="Debian Jessie 8.0 (64-bit)(testing)")
xe template-param-set uuid=$newUUID \
other-config:default_template=true \
other-config:debian-release=jessie
xe template-list uuid=$newUUID
...
#/> vi debian_jessie_i386.sh
...
#!/bin/sh
baseUUID=$(xe template-list name-label="Debian Wheezy 7.0 (32-bit)" --minimal)
newUUID=$(xe vm-clone uuid=$baseUUID new-name-label="Debian Jessie 8.0 (32-bit)(testing)")
xe template-param-set uuid=$newUUID \
other-config:default_template=true \
other-config:debian-release=jessie
xe template-list uuid=$newUUID
...
#/> sh debian_jessie_amd64.sh
#/> sh debian_jessie_i386.sh

Alles anzeigen

Regards
fnu

Per Default werden alle VMs eines XenServer oder Xen als Kernelstack an die gleiche einfache (Kernel-)Bridge angebunden. Das hat Vorteile, einfach Konfiguration ohne weitere Optionen, und Nachteile, das virtuelle Netzwerk der VMs ist nicht wirklich gut zu verwalten in seinem Bridge-Netzwerk, wie auch alle Kommunikation zwischen den VMs erst den Virtualisierungs-Host verläßt durch das physische Hausnetz geht und dann wieder zurückkommt. Ganz zu schweigen des hart definierten Ressourcen-sharings ...

Besser wäre es wenn die VMs innerhalb des Hypervisors ein Netzwerk mit einem virtuellen Switch bilden, wo alle VMs angebunden wären. Die Kommunikation würde per Punkt-zu-Punkt Verbindung innerhalb der Farm bleiben, was viele Vorteile mit sich bringt. Für die die mit VMware ESXi/VSphere arbeiten ist das ein alter Hut, da ist das von Haus aus so, initial wird eine einfacher Switch angelegt, der funktional in etwa auf dem derer ist die wir zu Hause einsetzen, preiswert, sparsam aber völlig ausreichend. Es gibt keinen großen Unterschied zum Bridge Betrieb in Xen, ausser das VM zu VM Kommunikation eben nicht dieses virtuelle Netzwerk verläßt. Alternativ kann man bei VMware hochfunktionale, managebare Switches definieren, wie auch bei XenServer Open vSwitch mitkommt und gesondert aktiviert werden muß:

|------|-------|VM|
| v  x |-------|VM|
| S  e |-------|VM|
| w  n |Uplink|     -----------------   
| i  b | Port |-----|Ethernet-Switch|
| t  r | ethX |     -----------------   
| c  0 |-------|VM|
| h    |-------|VM|
|------|-------|VM|

Per SSH auf den XenServer anmelden:

#/> xe-switch-network-backend openvswitch
Cleaning up old ifcfg files
Enabling openvswitch daemon
Configure system for openvswitch networking
You *MUST* now reboot your system

Da wir natürlich auf allen VM die XenTools installiert haben, genügt hier ein "reboot", der Hypervisor fährt alle VMs sauber runter. Danach wird die bei der Installation angelegte Bridge "xenbr0" automatisch zum virtuellen Switch und unser "eth0" wie u.a. bei VMware zum Kabel "nach draussen":

#/> ovs-vsctl show
8d010a1d-a6a2-4d3a-beb5-2dd880fa3251
    Bridge "xenbr0"
        fail_mode: standalone
        Port "vif8.0"
            Interface "vif8.0"
        Port "vif4.0"
            Interface "vif4.0"
        Port "vif5.0"
            Interface "vif5.0"
        Port "vif1.0"
            Interface "vif1.0"
        Port "vif6.0"
            Interface "vif6.0"
        Port "xenbr0"
            Interface "xenbr0"
                type: internal
        Port "eth0"
            Interface "eth0"
        Port "vif3.0"
            Interface "vif3.0"
        Port "vif2.0"
            Interface "vif2.0"
    ovs_version: "1.4.6"

Die VMs (vif) verbinden sich automatisch, weil es nur eine Möglichkeit gibt, aber jetzt gäbe es die Möglichkeit VMs an einen zweiten Switch abzutrennen, z.B. für NAT-Betrieb über eine NAT Appliance, die beide vSwitches verbindet.

Open vSwitch kann sehr viel, Bonding, QoS, VLAN, etc., ich mühe mich noch durch die Dokumentation, es gäbe auch eine Open vSwitch Applicance zu grafischen Administration. Aber mir reicht erstmal "der einfache" Switch-Betrieb, meinen Windows-VMs (HVM) merke ich das schon deutlich an, wobei das vorher alles andere als langsam war.

Zum Test habe ich eine "Windows 8" VM an den "Windows Server 2012 Essentials" angebunden, der Datentransfer innerhalb des XenServers z.B. für Backup ist pfeilschnell.

[edit]
Mit der Veröffentlichung von XenServer 6.2 hat Citrix die Entwicklung der Open vSwitch Appliance (DVSC) eingestellt. Die letzte Version gibt es immer noch frei zum Download, man muß sich bei Citrix annmelden, und wird auch hier noch funktionieren.

Die Anforderungen an diese sind aber hoch, min. 2GB Hauptspeicher für die resultierende VM, macht wenig Sinn für uns mit einem XenServer und ein oder zwei vSwitches, also besser doch die Dokumentation zum CLI lesen ...
[/edit]

Regards
fnu
*) http://virtualizationreview.co…witch-in-xenserver-6.aspx

kerberos187, stmeyer, ranseyer, austen

Danke Euch, freut mich wenn's weiterhilft.

Alle Lösungen haben Vor- und Nachteile, man muß eben die Richtige für den richtigen Zweck nutzen. Wie schon mal geschrieben geht es mir um DVB Virtualisierung ohne VT-d, dafür ist Xen eben perfekt geeignet, also z.B. auch für die "hp micro Proliant NXXL" die ja wohl einige Nutzer am Start haben.

Mit ArchLinux kämpfe ich noch ein wenig, obwohl es sich sauber in die PV installiert, mag "pygrub" die VM dann nicht booten, aber das bekommen wir noch sortiert, bin wohl auch nicht alleine mit dem Issue.

Nächster Punkt ist erstmal eine möglichst einfache Lösung externe Platten, nicht virtualisiert, an die VMs für Backups anzubinden.

Regards
fnu

Sicherungen sind eine durchaus lästige Pflicht, aber eben eine Pflicht. Diese Sicherungen sollten auf nicht virtualisierten Medien erfolgen, damit man diese beliebig verarbeiten kann. Natürlich sind die VM per Netzwerk erreichbar bzw. erreichen andere nicht virtualisierte Maschinen per CIFS, FTP, SFTP etc.

Aber diese Netzwerkübertragungen sind nicht unbedingt immer der praktikabelste Weg, es wird Massenspeicher benötigt der nativ an die VMs durchgereicht wird. USB Sticks und/oder HDDs sind ja bei vielen hierfür vorhanden und Citrix hat in Xen[Center] auch daran gedacht, aufgrund des Kernels nur USB2, dafür aber FullSpeed, aber auch da profitiert frau/man von USB3 Geräten.

Die USB Geräte an den XenServer anschließen und XenCenter öffnen

• Im Tree "Removable Storage" anklicken und prüfen ob alle da sind
• Die gewünschte Ziel-VM auswählen, Storage, Attach
  =>in meinem Beispiel meine 1TB USB Platte an W2012 für die Serversicherung
  => die HDD wird automatisch ins System eingebunden
• Wenn man fertig ist, Ziel-VM, Storage, Storage auswählen, Detach

Der USB Storage wird nicht nicht als USB/Removable Storage durchgereicht, sondern als Disk-Device und muß unter Linux manuell montiert werden:

#/> dmesg
...
[65933.050028] blkfront: xvdb: barrier: enabled
[65933.051780]  xvdb: xvdb1
...
#/> sudo mount /dev/xvdb1 /mnt
#/> mount -v.../dev/xvdb1 on /mnt type vfat (rw)
...
#/> sudo umount /mnt

Nach dem "umount" kann man den USB Massenspeicher wieder detach'en.

Wer bei Windows die Sicherheit möchte, muß entweder über den Diskmanager die Platte demontieren, was dem "umount" entspricht, oder die Maschine runterfahren. Alternativ die Disk vorher überprüfen lassen oder nach erst einigen Minuten nach einem letzten Schreibvorgang detache'en ...

[edit] Bin noch nicht 100% sicher, aber es scheint, als ob die XenTools dafür sorgen, dass das externe Storage sauber aus der Win-HVM genommen wird und nicht korrumpiert, sehr geil Citrix. [/code]

Zum Durchsatz komme ich in einem nächsten Beitrag.

Regards
fnu

Hier möchte gerne ein Wort über den Durchsatz von und zu virtuellen Maschinen wie auch der o.a. angerissenen USB Geräte verlieren, 1x 1TB externe USB2.0 HDD, 1x 32GB USB3.0 Stick.

"ranseyer" hatte ja auch nach der CIFS Performance gefragt gehabt.

Da ich eh ein paar dicke ISOs für die Tests benötigte, habe ich deren Übertragung eben dokumentiert, Hausnetz: 1Gb/s.

• 1.) Screenshot: Transfer von 2 Windows DVD ISOs per CIFS von meinem Desktop zur HVM mit Windows Server 2012
• 2.) Screenshot: Transfer von 2 anderen Windows DVD ISOs von meinem Desktop per Filezilla (SFTP) auf eine Ubuntu Precise PV
• 3.) Screenshot: Durchsatz innerhalb der W2012 HVM beim Transfer der DVD ISOs von der System-HDD auf die externe 1TB USB2.0 HDD
  => da ich die Platte schon lange besitze und kenne, kein Unterschied zum Transfer auf einer physischen Maschine

Den Transfer innerhalb der Ubuntu PV konnte ich natürlich nicht bildlich dokumentieren, daher per cmdline rsync der Transfer von der Systemplatte auf den Stick:

#/> sudo rsync --progress *.iso /mnt/
sending incremental file list
de_windows_7_ultimate_with_sp1_x64_dvd_u_677306.iso  3268147200 100%   29.28MB/s    0:01:46 (xfer#1, to-check=1/2)
de_windows_7_ultimate_with_sp1_x86_dvd_u_677456.iso  2509058048 100%   27.55MB/s    0:01:26 (xfer#2, to-check=0/2)
sent 5777910661 bytes  received 50 bytes  29860003.67 bytes/sec
total size is 5777205248  speedup is 1.00

Auch hier kein Unterschied zu einer physischen Maschine, der USB3 Stick ist beim Schreiben an einem USB2 Anschluß einfach genial ...

Regards
fnu