yaVDR64 0.5 goes Xen Hypervisor - VDR Server als Hypervisor oder in VM inkl. DVB Karten

@yavdr fans

Da das Thema Homeserver Virtualisierung hier regelmäßig auftaucht und die gängigen und beliebten Lösung vSphere Hypervisor (früher ESXi) und Proxmox 2.x nur mit spezifischer Hardware DVB Karten an Clients durchreichen, habe ich mich an Xen erinnert. Xen ist ein beliebig komplexe und schwierig zu bedienende Alternative zu VMWare & QEMU/KVM, wofür ich sie offen gestanden eigentlich nicht mag. Aber Xen wurde im Ursprung genau dafür entwickelt beliebige Hardware an Clients durchzureichen, zu einer Zeit als noch keiner über VT-d oder IOMMU gesprochen hat.

Nun bin ich ja von Haus aus Ubuntu lastig und wollte vermeiden, eine Lösung zu skizzieren die auf einem alten Kernel der Version 2.6.32 basiert und aktuelle SandyBridge HW schlicht zu warm arbeiten läßt. Alle Xen affinen Distros wie RedHat, Fedora, SuSE, Debian und auch Appliances wie XCP (xen.org) basieren auf dieser betagten Kernelversion. Nach einiger Suche bin ich über diese Meldung gestolpert: XCP in Ubuntu Server 12.04 LTS: "apt-get install xcp-xapi"

Dazu muß man wissen, früher hatte Ubuntu Sever eine andere Kernelversion, als die Desktopversion, das ist bei Ubuntu 12.04 nicht mehr so. Es gibt zwar ein virtualles Paket "linux-image-server", das zieht aber den gleiche Paket "linux-image-3.2.0-xx-generic" mit, wie das virtuelle Paket "linux-image-generic". Kurzum, yaVDR0.5* das auf Precise basiert, beinhaltet Xen/XCP-XAPI ...

Nun zu den Spielregeln dieses Threads, ich hoffe der Titel sagt schon viel dazu aus:

• Dies ist kein fertiges HowTo, sondern der Versuch mal zu skizzieren was prinzipiell möglich ist.
• Der Thread ist nichts für Anfänger und Weicheier, das Thema setzt ein gehöriges Maß an IT und Linux Kenntnissen vorraus.
• Nicht auszuschließen, das wir am Ende dieses Threads zu eine Noob tauglichen Lösung kommen, in einem Jahr oder so ...
• Ich weiß auch nicht alles, ich schreibe im Prinzip nach bestem Wissen und Gewissen das nieder, was ich in den letzten 24h aufgesaugt habe.
• Für die Administration per XenCenter u.ä. muß der "root" User bei Ubuntu freigeschalten werden.
• Wer seine yaVDR 0.5 Installation als Xen Hypervisor benutzt, begibt sich weit ausserhalb des Supports durch das yaVDR Teams!

Was sind die Vorteile:

• Dieser Weg von Xen/XCB-XAPI basierend auf Ubuntu 12.04, also Ubuntu Server, Ubuntu Desktop und auch yaVDR, ermöglicht die gewohnte Systemaktualisierung über die bekannte Repositories.
• Ubuntu LTS 12.04 hat wird vom Ubuntu Team 5 Jahre lang unterstützt
• Da yaVDR den Hypervisor gibt, wäre eine PCI/PCIe Virtualisierung nicht mehr nötig, da die DVB Karten direkt im Hypervisor (Dom0) zur Verfügung stehen.

Was ist nötig:

• Ein frische yaVDR 0.5 Installation auf dem Server, das ganze LVM basiert, Beispiel 1TB:
  => Bei der Installation manuelles Partitionieren auswählen
  => (Bei EFI Installationen eine EFI Partition à 200MB)
  => Eine Boot Partition mit 256MB, Filesystem: ext3, Mount: "/boot"
  => Der Rest der Platte als LVM Partition
  => Eine Volume Gruppe "yavdr"
  => Ein LV "root" mit 8GB, Filesystem: ext4, Mount: "/"
  => Ein LV "swap" mit 2/4/8GB je nach System, Filesystem: Swap
  => Ein LV "iso" mit 64GB, Filesystem: ext4, Mount: "/srv/xen/iso_import"
  => (Ein LV "video" mit 500GB, Filesystem: ext4/xfs, Mount: /srv/vdr/video00) wenn gewünscht ...
  => Ein LV "pool" mit 400GB, kein Filesystem, kein Mount, da landen später die Xen-Clients drauf.
• Der yaVDR Installation folgen und nach Beendigung per WFE das Frontend auf Headless Server umstellen und die letzten Updates reinziehen
• Nun XCB-XAPI anhand dieser Anleitung installieren: Step by step guide to setting up Xen and XAPI (XenAPI) on Ubuntu 12.04 and managing it with Citrix XenCenter
  => Achtung: Alle Änderungen an der grub-Konfiguration müssen bei yaVDR Basis per Template gepflegt werden!
• Wenn Xen/XCB läuft, das ISO Repo definieren, wie z.B. hier beschrieben, wie man den Storage-Pool für Clients definiert, steht im oberen HowTo.
• Wie das dann fertig im XenCenter aussehen könnte, zeigt der angehängte Screenshot.
  => Maschine: Biostar Mainboard mit AMD785 Chipsatz, Athlon II X2 240, 2x2GB, 3Ware 9500S-4LP mit nur einer WD10EADS als RAID Device, hatte nicht mehr übrig ...

Auf wenn man im Prinzip keine PCIe Karte mehr durchreichen müßte, hab ich dennoch mal das Thema "erforscht", Dokumenation gibt es, aber sehr uneinheitlich. Was habe ich bis jetzt, meine "L4M DVB-S2 V6.2" wird vom Hypervisor als "seized" gekennzeichnet, was wohl bedeutet, ich könnte sie an einen Client durchreichen:

#/> lspci
...
01:05.1 Audio device: Advanced Micro Devices [AMD] nee ATI RS880 HDMI Audio [Radeon HD 4200 Series]
02:00.0 Multimedia controller: Digital Devices GmbH Octopus LE DVB adapter
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
04:05.0 RAID bus controller: 3ware Inc 9xxx-series SATA-RAID

#/> cat /etc/modules
xen-pciback

#/> cat /etc/default/grub
...
GRUB_CMDLINE_LINUX="xen-pciback.permissive xen-pciback.hide=(02:00.0) reassign_resources"
...

#/> dmesg|grep pciback
[    8.356697] pciback 0000:02:00.0: seizing device
[    8.356786] pciback 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    8.356793] pciback 0000:02:00.0: PCI INT A disabled
[    8.359096] xen-pciback: backend is passthrough

#/> sudo xm pci-list-assignable-devices
0000:02:00.0

Was steht noch aus:

• Die Beendigung der Ubuntu Installation aus dem Screenshot, hab leider keine Tastatur in der Console vom XenCenter. Ist vmtl. nur eine Kleinigkeit, aber auch die muß man lösen
• Gucken ob ich die DVB Karte durchreichen kann, wenn die Installation fertig ist
• Testinstallation "Windows Server 2012 Essentials", damit da mal ein wenig Last auf die Installation kommt und ich das eh für meine Win-Clients irgendwann einsetzten möchte
• Testinstallation auf meinem eigentlichen Server mit Intel SandyBridge HW ...

So, nun bin ich gespannt ob sich da jemand dran wagt, was von Euch dazu kommt und es irgendwann tatsächlich für einen Noob freundlicheren Weg reicht ...

Beschreibung für Ubuntu 20.04: https://www.opensdev.com/2020/07/20/Xen_Setup.html

Regards
fnu

Zitat von MarkusH

VMware war die einzige Alternative wo das sauber lief, ich find halt dass das etwas oversized ist für zuhause.

Das gibt sich nichts, entweder sind alle Lösungen oversized oder keine. Alle haben irgendwie Vorteile und auch Nachteile. Proxmox ist eine wirklich runde Lösung, das Web-Management 1a, HA Features etc. Aber KVM ist etwas grob in der Resourcen Zuteilung zwischen den Clients, da kann schon mal eine Maschine die andere deadlock'en, ist aber kein Proxmox Problem, sondern KVM generell. Diese Zuteilung kann VMWare IMHO am Besten, erstaunlich wie rund alle Clients auch unter Last laufen ohne sich gegenseitig zu stören, aber halt auch nicht besonders schnell. Bei Xen hatte ich den Eindruck die Resourcen Zuteilung ist ebenso gut, aber die Clients laufen durchaus schneller, Ubuntu installierte sich ebenso schnell wie auf eine physischen Maschine. Noch besser wurde es mit den XenServer Tools, nur dann hatte ich das Ding irgendwann tot konfiguriert, war halt nur eine Testmaschine ...

Alles bezogen auf normale PCs wie wir sie zu Hause verwenden!

Zitat von MarkusH

Vor allem gibts den Sphere Client nur für Windows.

Nun XenCenter gibt es auch nur für Windows und ansonsten sieht es bei Xen echt Essig aus mit brauchbaren Tools. Ohne Frage sehr mächtige Kommandozeile, aber hey, wenn der Server mal läuft geht mal alle 6 Monate mal dran, solange merkt sich doch keiner die cmdline Befehle. Da glänzt ganz hell das Web-Management (JSON basiert) von Proxmox mit seiner Plattformunabhängigkeit. Das wäre was für XCP-XAPI, weiß aber gar nicht ob es da nicht schon was gibt.

Das Problem mit der Tastatur in der Client-Console vom XenCenter habe ich nicht gelöst bekommen, konnte mich aber per VNC @ SSH Tunnel an die Clients verbinden und bedienen. Nur hatte ich ein seltsames Tastatur-Mapping, welches ich nicht beeinflussen konnte.

Das Thema hier ist nix kurzfristiges und Bedarf viel Geduld, aber evtl. kommt irgendwann was brauchbares für alle bei raus.

Regards
fnu

Zitat von DaKilla

Du kannst die Resourcen Zuteilung manuell vornehmen.

Das kann man bei jeder der Lösungen, aber darum geht es gar nicht, sondern was die Virtualisierung am Ende draus macht ...

Noch Eingaben von Deiner Seite zu Xen/XCP-XAPI? Best Practise PCI Virtualisierung, Management Software etc.?

Regards
fnu

@DaKilla

Wenn Du nicht möchtest das ich Deine OT Posts hier löschen/verschieben lasse, war das bitte Dein letzter OT Post hier. Wenn Du das für vSphere wichtig findest mach bitte einen eigenen Thread auf und diskutiere das dort. Und ja, Du hast bestimmt Recht, sollte beachtet werden, aber dennoch ganz andere Baustelle!

Das Thema heißt Xen @ yaVDR und nicht yaVDR @ vSphere Hypervisor. Man kann sicher gerne mal einen Themen-bezogenen Vergleich vSphere, KVM, Xen bringen.

Regards
fnu

PS.: Vielleicht machst Du mal wirklich einen eigenen Thread auf: "Offene Diskussion VDR @ Virtualisierung"? Da kann dann alles offen angesprochen und auch getrollt werden ...

@all

So, habe mich noch weiter mit dem Thema xen @ yavdr(precise) befasst. Der Citrix like Ansatz mit XCP/XAPI ist von der Idee ok, aber weit weg von einer runden Lösung. Mir gefällt das nicht wirklich, die Konsolen im XenCenter sind weder für die Domain-0 noch für die VMs/DomU nutzbar. Man kann zwar VNC per SSH-Tunnel verbinden, aber VNC ist halt irgendwie in der Entwicklung stehengeblieben. Ausserdem passt das Keyboard-Mapping nicht, wobei ich keinen Lösungansatz dazu finde. Also habe ich mich erstmal wieder auf das wesentliche konzentriert, wie funktionierts und PCI Virtualisierung ohne Directed-I/O (IOMMU/VT-d).

Nachdem inzwischen meine AMD HW ein neues Zuhause gefunden hat, habe ich mit anderer HW weitergetestet: Fujitsu D30701-S11 (Q67), Core i3 2120, ..., wie man sieht beherrscht die HW wegen der CPU kein "VT-d", muß also mit "Soft IOMMU" arbeiten. Wie gehabt yaVDR 0.5 mit LVM installieren oder eben Ubuntu Server. Xen wie oben oder hier beschrieben aktivieren. Da danach yaVDR bzw. Server direkt eine virtuelle Maschine wird kann man deren Resourcen auch beschränken, daher sieht meine grub config so aus:

GRUB_DEFAULT="Xen 4.1-amd64"
#GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm=force i915.i915_enable_rc6=7"
GRUB_CMDLINE_LINUX="xen-pciback.permissive xen-pciback.hide=(01:00.0) reassign_resources"
GRUB_CMDLINE_XEN="dom0_mem=512M,max:1G dom0_max_vcpus=1"

Damit wird der Xen-Subkernel aktiviert, die SandyBridge HW Stromspar Tricks angeschaltet (für AMD unnötig), weil die GT-Grafik zur Domain-0 gehört. Die Domain-0 darf sich zw. 512-1024MB Hauptspeicher von 8G gönnen und eine VCPU. Hier übergebe ich direkt die pciback Konfiguration, weil man damit das Kernel-Module der "L4M DVB-S2 V.6.2" nicht blacklisten muß. Das Kernel-Modul "xen-pciback" muß aber immer noch per "/etc/modules" geladen werden. Nach dem Reboot sieht man das dann auf der Domain-0 so:

...01:00.0 Multimedia controller: Digital Devices GmbH Octopus LE DVB adapter...

dmesg|grep pciback
[    0.000000] Command line: placeholder root=/dev/mapper/vg00-root ro xen-pciback.permissive xen-pciback.hide=(01:00.0) reassign_resources pcie_aspm=force i915.i915_enable_rc6=1
[    2.032815] Kernel command line: placeholder root=/dev/mapper/vg00-root ro xen-pciback.permissive xen-pciback.hide=(01:00.0) reassign_resources pcie_aspm=force i915.i915_enable_rc6=1
[    6.267266] pciback 0000:01:00.0: seizing device
[    6.267412] pciback 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    6.267419] pciback 0000:01:00.0: PCI INT A disabled
[    6.270940] xen-pciback: backend is vpci

xm pci-list-assignable-devices
0000:01:00.0

ll /dev/dvb*
ls: Zugriff auf /dev/dvb* nicht möglich: Datei oder Verzeichnis nicht gefunden

Das Kernel-Module "ddbridge" wird nicht geladen, keine Device angelegt und die Karte steht als PCI Device für virtuelle Maschinen zur Verfügung. Als Test habe ich eine virtuelle Maschine, bei Xen DomU, als PV installiert. In dem oben schon mal verlinkten Dokument, steht im groben Zügen wie das geht. Ihr müßt auf der Dom0 noch manuell das Paket "python-lxml" installieren, sonst gibt es einen Fehler beim "xm new ...". Irgendwann habe ich meine Maschine am laufen:

xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   511     1     r-----     21.5
precise                                      1   512     1     -b----      9.8

cat /etc/xen/precise.cfg
name = "precise"
memory = 512
disk = ['phy:/dev/vg00/precise,xvda,w']
pci=['01:00.0']
vif = ['bridge=xenbr0']
bootloader = "pygrub"

Wie man sieht habe ich der Maschine direkt die PCIe Karte zugewiesen und sehe auf der Dom0 das:

[   85.000705] xen-pciback: vpci: 0000:01:00.0: assign to virtual slot 0
[   87.610623] pciback 0000:01:00.0: Driver tried to write to a read-only configuration space field at offset 0x72, size 2. This may be harmless, but if you have problems with your device:
[   88.369622] pciback 0000:01:00.0: enabling device (0000 -> 0002)
[   88.369635] pciback 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16

Und auf der virtuelle Maschine das:

lspci
00:00.0 Multimedia controller: Digital Devices GmbH Octopus LE DVB adapter

ll /dev/dvb/*
/dev/dvb/adapter0:
insgesamt 0
crw-rw---- 1 root video 212, 0 Okt 15 00:56 demux0
crw-rw---- 1 root video 212, 1 Okt 15 00:56 dvr0
crw-rw---- 1 root video 212, 3 Okt 15 00:56 frontend0
crw-rw---- 1 root video 212, 2 Okt 15 00:56 net0
/dev/dvb/adapter1:
insgesamt 0
crw-rw---- 1 root video 212, 4 Okt 15 00:56 demux0
crw-rw---- 1 root video 212, 5 Okt 15 00:56 dvr0
crw-rw---- 1 root video 212, 7 Okt 15 00:56 frontend0
crw-rw---- 1 root video 212, 6 Okt 15 00:56 net0

[    2.474528] pcifront pci-0: Installing PCI frontend
[    2.474578] pcifront pci-0: Creating PCI Frontend Bus 0000:00
[    2.474725] pci 0000:00:00.0: [dd01:0003] type 0 class 0x000480
[    2.474844] pci 0000:00:00.0: reg 10: [mem 0xfbb00000-0xfbb0ffff 64bit]
[    2.476574] pcifront pci-0: claiming resource 0000:00:00.0/0
[    2.996989] cxd2099: module is from the staging directory, the quality is unknown, you have been warned.
[    3.234030] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
[    3.234211] DDBridge 0000:00:00.0: enabling device (0000 -> 0002)
[    3.234268] DDBridge 0000:00:00.0: Xen PCI mapped GSI16 to IRQ27
[    3.234278] DDBridge driver detected: Digital Devices Cine S2 V6 DVB adapter
[    3.234297] HW 00010006 FW 00010002[    3.235297] Port 0 (TAB 1): DUAL DVB-S2
[    3.235882] Port 1 (TAB 2): NO MODULE[    3.236516] Port 2 (TAB 3): NO MODULE
[    3.237020] DVB: registering new adapter (DDBridge)
[    3.411420] LNBx2x attached on addr=a
[    3.420381] stv6110x_attach: Attaching STV6110x
[    3.420383] attach tuner input 0 adr 60
[    3.420385] DVB: registering adapter 0 frontend 0 (STV090x Multistandard)...
[    3.420462] DVB: registering new adapter (DDBridge)
[    3.456318] LNBx2x attached on addr=8
[    3.456326] stv6110x_attach: Attaching STV6110x
[    3.456329] attach tuner input 1 adr 63
[    3.456333] DVB: registering adapter 1 frontend 0 (STV090x Multistandard)...

Man beachte die PCI ID ist nun anders. Hier fand ich den Hinweis, das auf dem Client per grub folgendes übergeben werden sollte:

...GRUB_CMDLINE_LINUX="iommu=soft swiotlb=force console=hvc0"...

Also iommu & swiotlb, das Verhalten war aber beim Ubuntu Client mit und ohne das gleiche, schaden tuts aber wohl auch nicht.

=> Diese CMDLINE Parameter müssen unbedingt übergeben werden, wenn die zu virtualisierende DVB Karte ihre Firmware aus einer Datei bezieht. DomU nach erstmaliger Änderung unbedingt "ausschalten", reboot endet vmtl. in Kernel-OOPS.
=> Evtl. kann es hilfreich sein "pci=nomsi" zusätzlich zu übergeben.

Eben noch noch einen schmalen VDR mit streamdev-server aus unserem PPA installiert und gestartet, et vòila:

Oct 15 00:56:14 precise vdr: [738] probing /dev/dvb/adapter0/frontend0Oct 15 00:56:14 precise vdr: [738] creating cDvbDeviceOct 15 00:56:14 precise vdr: [738] new device number 1Oct 15 00:56:14 precise vdr: [914] epg data reader thread started (pid=738, tid=914)Oct 15 00:56:14 precise vdr: [914] reading EPG data from /var/cache/vdr/epg.dataOct 15 00:56:14 precise vdr: [914] epg data reader thread ended (pid=738, tid=914)Oct 15 00:56:14 precise vdr: [913] video directory scanner thread started (pid=738, tid=913)Oct 15 00:56:14 precise vdr: [912] video directory scanner thread started (pid=738, tid=912)Oct 15 00:56:14 precise vdr: [913] video directory scanner thread ended (pid=738, tid=913)Oct 15 00:56:14 precise vdr: [912] video directory scanner thread ended (pid=738, tid=912)Oct 15 00:56:14 precise vdr: [738] frontend 0/0 provides DVB-S,DVB-S2 with QPSK ("STV090x Multistandard")Oct 15 00:56:14 precise vdr: [738] probing /dev/dvb/adapter1/frontend0Oct 15 00:56:14 precise vdr: [738] creating cDvbDeviceOct 15 00:56:14 precise vdr: [738] new device number 2Oct 15 00:56:14 precise vdr: [917] section handler thread started (pid=738, tid=917)Oct 15 00:56:14 precise vdr: [916] tuner on frontend 0/0 thread started (pid=738, tid=916)Oct 15 00:56:14 precise vdr: [916] cTimeMs: using monotonic clock (resolution is 1 ns)Oct 15 00:56:14 precise vdr: [738] frontend 1/0 provides DVB-S,DVB-S2 with QPSK ("STV090x Multistandard")Oct 15 00:56:14 precise vdr: [738] found 2 DVB devices

Und der VDR versucht natürlich direkt die Device zu verwenden, hatte aber kein Kabel dran ...

Oct 15 00:56:23 precise vdr: [916] frontend 0/0 timed out while tuning to channel 1, tp 112187
Oct 15 00:57:22 precise vdr: [919] frontend 1/0 timed out while tuning to channel 101, tp 111389
Oct 15 00:57:23 precise vdr: [916] frontend 0/0 timed out while tuning to channel 100, tp 111261...

Hardware Virtualisierung funktioniert mit Xen auch ohne IOMMU/VT-d, es fehlen jetzt aber noch Erfahrungswerte und Xen ist nicht wirklich "schön" zu bedienen. Bei Precise ist Xen 4.1 an Board, das bedeutet man kann sowohl "xm" als auch schon "xl" als Toolstack verwenden. Für libvirt ist z.B. "xm" beizubehalten und bei "xl" fehlen noch einige Dingen gegenüber Xen 4.2.

Regards
fnu

PS.: Was echt auffällt ist die Performance der VMs/DomUs. Fiel mir schon mit der AMD Hardware auf, es gibt quasi keinen Unterschied zu einem physischen Host. Ein Tod muß man wohl sterben, entweder durchdachtes Bedienkonzept oder schnelle VMs ...

@all

Habe mal wieder Zeit gefunden mich dem Thema weiter zu befassen, ein Hypervisor macht ja nun nur mit mehreren virtualisierten Maschinen Sinn. Einen habe ich ja schon, den oben beschriebenen VDR Server, ebenfalls Ubuntu LTS 12.04 basiert, ausgestattet mit einer L4M Dual DVB-S2 V6.2, durchvirtualisiert ohne VT-d fähig Hardware. Das würde auch gut mit den HP Micro Proliant N36L/N40L funktionieren und deren AMD Hardware funktionieren, die einige hier am Start haben.

Inzwischen habe ich auf das Management per "libvirt" umgestellt, die kleine Änderung dazu ist in der bereits mehrfach genannten Ubuntu Xen Community Documentation beschrieben. Wenn ihr die Datei "/etc/xen/xend-config.sxp" dann eh editiert, fügt weiter unten noch die Zeile im passenden Abschnitt hinzu, xend oder den ganzen Server danach neu starten:

(keymap 'de')

Damit wäre für Xen global das deutsche Tastatur Layout gültig. Diese läßt aber auch für jeden einzelnen Server anders definieren. Der "virt-manager" läßt sich auch sehr gut mit Windows Desktops nutzen, "puTTY" & "Xming" sind Eure Freunde.

Nun hat man ja auch Windows Desktops in der Familie und der MS Home Server ist durchaus verbreitet. Daher habe ich mir den Nachfolger "Windows Server 2012 Essentials" vorgenommen. Den hatte ich schon mehrfach auf Bare-Metal installiert, wie auch in VMWare & KVM Installationen, machte einen vernünftigen Eindruck. Nun also als HVM auf dem Xen-Hypervisor. Im Gegensatz zum Linux PV (s.o.) muß der Host hier "VT-x" beherrschen, wie bei VMWare, Proxmox etc., bitte nicht mit "IOMMU/VT-d" verwechseln. Folgende Konfiguration:

name = "w2012ess"
kernel = 'hvmloader'
builder = 'hvm'
device_model = 'qemu-dm'
vcpus = 4
memory = 2048
xen_platform_pci=1
#vif = [ 'type=ioemu, bridge=xenbr0, model=e1000' ]
vif = [ 'bridge=xenbr0, type=paravirtualised' ]
#disk = [ 'phy:/dev/vg00/w2012ess,xvda,w', 'file:/var/lib/xen/images/w2012ess/WindowsServer2012Essentials-ReleaseCandidate-German-Install.iso,xvdc:cdrom,r' ]
disk = [ 'phy:/dev/vg00/w2012ess,xvda,w' ]
# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
#boot = "dc"
acpi = 1
apic = 1
hap=1
hpet=1
localtime = 1
sdl = 0
vnc = 1
vncconsole = 1
serial = 'pty'
usb = 1
usbdevice = 'tablet'
viridian = 1

Pfade eben an Euer Layout anpassen. Wie man sieht habe ich ein paar Einträge "doppelt" und kommentiert, das liegt daran, das man während der Installation ein Config "A" benötigt und später nach Installation der PV-to-HVM Treiber eben ein paar Anpassungen machen muß. Treiber gibt es hier, drauf achten ob man x64 oder x86 benötigt und das richtige runterladen, diese Treiber sind signiert. Am Besten "complete install", Maschine runterfahren, konfiguration anpassen, wieder starten.

xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  1021     1     r-----    384.9
vdrserv                                      2   512     1     -b----      4.0
w2012ess                                     1  2048     2     -b----    110.6

Zur VNC Ausgabe kann man per "virt-manager" oder "xenwatch" verbinden, ersterer ist besser, ein paar Screenshots dazu im Anhang. Achtet auf den Device Manager, den PV-to-HVM Treibern und den ausgehandelten NIC Speed von 10Gbit/s. Das gilt aber nur für das virtualisierte Netzwerk, hinter dem Bare-Metal habe ich auch "nur" 1Gbit/s ...

[EDIT]

Es ist besser den Netzwerktreiber des Univention Pakets nicht zu installieren. Ich hatte da allerlei Probleme, ähnlich meinen KVM/Proxmox Erfahrungen. Der Rest der Treiber ist aber wichtig, erst dann hat man die Storage Leistung die man haben möchte. Also bei der Installation alles ausser dem Netzwerktreiber installieren lassen und im Gerätemanager den Xen Netzwerkadapter "disable'n" nicht deinstallieren, er kommt wieder ...

[EDIT]

Wenn Ihr "libvirt" installiert, wird leider auch ein DNS Server (dnsmasq@libvirt) in der Domain-0 mit aufgesetzt, der stört vmtl. bei den meisten, ausser ein NAT Layout wäre gewünscht. Hierzu folgende Befehle:

#/> virsh net-list --all
#/> virsh net-destroy default
#/> virsh net-autostart --disable default

Regards
fnu

PS.: Bevor Fragen kommen, ja ich weiß das "Windows Server 2012 Essentials" dieser Tage final erschienen ist, war aber zu faul das ISO zu ziehen ...

Zitat von MarkusH

Bei mir liegt die unter /var/lib/xend/domains/

Ja, das ist korrekt das diese XML Dateien dort liegen. Das ist quasi die Datenbank der laufenden bzw. angelegten Maschinen. Diese werden von xm|xl, libvirt o.ä. geändert, aber eher nicht händisch mit vi, ginge aber auch ...

Die von mir o.a. Datei lege ich z.B. unter "/etc/xen/..." als "w2012ess.cfg" bereit und nutze diese auch für Änderungen ...

#/> xm new /etc/xen/w2012ess.cfg => legt die neue Maschine permanent an
#/> xm list => listet alle laufenden Maschinen, auch gestoppte wenn permanent definiert
#/> xm delete w2012ess => löschte diese Maschine
#/> xm new /etc/xen/w2012ess.cfg => legt die Maschine evtl. geändert wieder an

Zu den angelegten Maschinen findet sich dann natürlich ein korrospondierende XML Datei unter "/var/lib/xend/..."

Nachtrag, unbedingt die HVM Treiber nutzten und installieren, aber nicht den Netzwerktreiber. Nach Installation das Gerät im Windows Device Manager einfach belassen bzw. deaktivieren (nicht löschen!), auch virtualisiert sind die Intel-NICs einfach besser, stabiler und zuverlässiger ...

Regards
fnu

Zitat von MarkusH

Zu spät ?(! Hab einfach das komplette Paket installiert. Schau mir das morgen nochmal, ich kann auch keine Windows Updates installieren. Jeder Versuch wird mit einem Bluescreen quittiert...

Du kommst ja noch auf die Maschine, per vnc auf die Console, beim NIC schauen wie die Treiber Datei heißt, das Interface im Gerätemanager deinstallieren und die zugehörige Datei auch ...

Das ist bei KVM/Proxmox im übrigen das gleiche Verhalten. Ich finde es echt erstaunlich das die Intel-NICs selbst virtualisiert die Besten sind ...

Regards
fnu

Zitat von MarkusH

Meinst du damit, dass der NIC-Treiber ist für die Bluescreens verantwortlich?

Hmm, könnte sein ja, warum nicht.

Hatte ich selbst nie, bei mir war es so das Updates unheimlich langsam reinkamen, so auf 14.4KBaud Niveau. Auf den Windows Clients DomUs konnte ich zwar den Connector von 2012 Essentials installieren, aber dieser dann nicht zum Server verbinden wollte. Allerlei Kleinigkeiten die komisch waren, während anderes ganz normal lief. Ich erinnerte mich aber dann an meine KVM/Proxmos Erfahrungen und habe den HVM NIC Treiber rausgenommen und wieder den Default e1000 emuliert, et voilá. Aber der Storage Treiber ist wie bei KVM/Proxmox sehr wichtig, der bringt erst den Speed den Du haben möchtest. Also alles davon installieren, ausser dem NIC Treiber, da einfach beim Bewährten bleiben ... sorry, das ich vergaß das hier zu schreiben, ich ändere es an passender Stelle.

Regards
fnu

Zitat von MarkusH

Muss mich jetzt erstmal ums passthrough kümmern, mal schauen !

Hmm, gut das Du mich erinnerst, wollte das PCI Passthru auch mal in eine Win DomU testen. Die pciback Konfig ist nicht nicht sonderlich aufwändig, siehe Post 9.

Regards
fnu

Zitat von fnu

wollte das PCI Passthru auch mal in eine Win DomU testen.

So, hier kann ich mal einen Haken dran machen, PCI Passthru in einer HVM geht mit Xen auch nur mit IOMMU/VT-d Unterstützung. PCI Passthru ohne IOMMU/VT-d funktioniert somit nur in PVs, was die Verwendung auf Linux Clients einschränkt.

Regards
fnu