Virtualisierung von Windows 2016 Server - 2x CPU, 8GB RAM - boot bleibt bei "Booting from DVD/CD" hängen

Die Virtualisierung von Windows 2016 Server (Download, 180 Tage Testlizenz) soll eine erste Testinstallation werden, auf welche dann NAV 2015 und - in einem weiteren virtuellen Win-2016-Guest - NAV 2018 gepackt werden soll.

Leider bootet UVMM die virtuelle Maschine nicht hoch: das ISO wird - als DVD eingebunden - erkannt, im VNC steht dann aber für Stunden “Booting from DVD/CD”.

In /var/log/syslog finde ich dann sowas wie /usr/lib/univention-virtual-machine-manager-daemon/uvmmd-check.sh, /var/log/libvirt/libvirtd.log gibt keine weiteren Meldungen aus, top zeigt als Hauptbeschäftigung das qemu-system-x86 an… wo kann ich schauen, was da wirklich hängt?

Hat meine eine virtuelle Maschine mit 2x CPU (von einer i7-3770 @ 3.40 GHz) und 8 GB RAM (von 16GB) zu wenig Power? Der Rechner ist kein echter Server, es handelt sich hier um einen ersten Testaufbau!

P.S.: eine Installation mit einem debian 9.4.0 netinst ISO läuft einwandfrei durch. Die Win-2016-ISO hat 6,6 GB, die netinst-ISO kommt auf 291 MB…

Kein UCS-Problem.

Siehe hier, Kasten “Wichtig”

Auwei. Vielen Dank für den Hinweis!

Huhu,

mir ist nicht ganz klar, was das Problem hier sein soll. Hab eben auf meiner noch schwachbrüstigeren UVMM-Test-Kiste eine VM mit einer CPU (i5-2400) & 2 GB RAM eingerichtet, und da bootet das Setup von Windows Server 2016 anstandslos. Hab’s jetzt nicht komplett installiert, aber… naja…

Gruß
mosu

Kannst Du mir bitte den Namen Deines ISO-files für das Windows Server 2016 Setups geben?

Das File, das ich heruntergeladen habe, heißt: “14393.0.161119-1705.RS1_REFRESH_SERVER_EVAL_X64FREE_DE-DE.ISO”.

Danke!

Sorrry, meinte den zweiten Kasten “Wichtig” in obigem Link. Der unter “RAM”. Link gefixt.

Wenn Ihr ISOs vergleicht, bitte auch sicherheitshalber die md5/sha Hashes vergleichen!

Huhu,

bei mir ist’s ein ISO aus unserer ActionPack-Subscription, keine Evaluierungsversion: SW_DVD9_NTRL_Windows_Svrs_2016_English_2_Std_DC_FPP_OEM_X21-22567.ISO

Gruß
mosu

An die DVDs der AP-Subscription komme ich seit ein paar Jahren nicht mehr.

Mein ISO stammt direkt von den MS-Seiten, am 14.03. runtergeladen. Ich müsste mir halt erst eine DL-DVD besorgen, ggf. liegt es auch daran, dass es nicht vom Laufwerk rennt, sondern als ISO eingebunden ist. Wenn ich heute nachmittag nach Büroschluss über eine stolpere, schreibe ich morgen durch, ob es daran lag.

md5/sha-Hash: 7e9cb8ddeb91ec4efdf6c55bf7e185b0 14393.0.161119-1705.RS1_REFRESH_SERVER_EVAL_X64FRE_DE-DE.ISO

Btw.: auch bei gleichen Ordner- und Dateiberechtigungen bekomme ich eine Fehlermeldung, wenn ich meine ISOs in meinen eigenen Pool “homedir_slow_hd” (gemountet in /home/MY_USER_NAME/virtdata2) lege. Ich muss die ISOs immer nach /var/lib/libvirt/images kopieren.
Die qcow2’s liegen im Pool “virtdata1” (gemountet unter /virt/virtdata1). Hier gibt es keine Probleme.
Was mache ich da falsch?

So sieht das aus:

root@ucs1:/var/lib/libvirt/images# ls -althZ /var/lib/libvirt/images/
insgesamt 7,0G
-rw-r--r-- 1 libvirt-qemu libvirt-qemu ? 291M Mär 19 15:49 debian-9.4.0-amd64-netinst.iso
drwx--x--x 2 root         root         ? 4,0K Mär 19 15:49 .
drwxr-xr-x 6 root         root         ? 4,0K Mär 19 10:17 ..
-rw-r--r-- 1 root         root         ? 149M Mär 15 16:24 KVM Windows drivers (virtio 1.1.126).iso
-r-------- 1 libvirt-qemu libvirt-qemu ? 6,6G Mär 15 14:15 14393.0.161119-1705.RS1_REFRESH_SERVER_EVAL_X64FRE_DE-DE.ISO

root@ucs1:/var/lib/libvirt/images# ls -althZ /home/MY_USER_NAME/virtdata2/
insgesamt 11G
drwxr-xr-x 2 libvirt-qemu      libvirt-qemu ? 4,0K Mär 19 16:18 uvmm_backups
drwxr-xr-x 5 libvirt-qemu      libvirt-qemu ? 4,0K Mär 19 15:47 .
-r-------- 1 root              root         ? 302M Mär 15 14:25 virtio-win-0.1.141.iso
-r-------- 1 libvirt-qemu      libvirt-qemu ? 1,4G Mär 15 14:05 ubuntu-17.10.1-desktop-amd64.iso
-r-------- 1 libvirt-qemu      libvirt-qemu ? 572M Mär 15 14:04 pfSense-CE-2.4.2-RELEASE-amd64.iso
-r-------- 1 libvirt-qemu      libvirt-qemu ? 6,6G Mär 15 14:04 14393.0.161119-1705.RS1_REFRESH_SERVER_EVAL_X64FRE_DE-DE.ISO
drwx------ 5 MY_USER_NAME Domain Users ? 4,0K Mär 15 12:58 ..
drwxr----- 3 libvirt-qemu      libvirt-qemu ? 4,0K Mär 15 11:00 NAV 2018
drwxr----- 5 libvirt-qemu      libvirt-qemu ? 4,0K Mär 15 10:59 NAV 2015
-rw-r----- 1 libvirt-qemu      libvirt-qemu ? 1,9G Mär 15 10:57 metropolis.7z
-rw-r--r-- 1 libvirt-qemu      libvirt-qemu ? 291M Mär 10 12:56 debian-9.4.0-amd64-netinst.iso

root@ucs1:/var/lib/libvirt/images# ls -althZ /virt/virtdata1/
insgesamt 4,4G
-rw------- 1 libvirt-qemu libvirt-qemu ? 1,9G Mär 20 14:17 debian4nuclos-0.qcow2
drwxr-xr-x 4 root         root         ? 4,0K Mär 19 15:42 .
-rwxr-xr-x 1 root         root         ? 2,6G Mär 14 14:43 nuclos_archiv.tar
drwxr-xr-x 2 root         root         ? 4,0K Mär 14 14:35 sources
-rw------- 1 libvirt-qemu libvirt-qemu ? 194K Mär 14 14:10 gen-srv-04-0.qcow2
drwxr-xr-x 3         1000 users        ? 4,0K Mär  8 12:44 ..
drwx------ 2 root         root         ?  16K Mär  8 12:43 lost+found

Huhu,

Wenn das Home-Verzeichnis nur und ausschließlich für dich selber lesbar ist, dann kann der User libvirt-qemu darauf nicht zugreifen, und damit auch nicht auf Unterordner. libvirt-qemu benötigt zumindest Execute-Rechte auf dem Verzeichnis. Kann auch über ACLs gemacht werden, z.B.: setfacl -m u:libvirt-qemu:x /home/MY_USER_NAME

Gruß
mosu

setfacl -m u:libvirt-qemu:x /home/MY_USER_NAME - klappte wunderbar :slight_smile:

Ich bin etwas durcheinander gekommen, da libvirt aus root (Owner und Group-Rechten) libvirt-qemu macht. Ich phantasierte, dass libvirtd das umso mehr mit meinen bescheidenen Rechten machen könne/würde. Wahrscheinlich - und logischerweise - halt nicht für alle übergeordneten Ordner. Danke für den Tipp und den Hinweis auf setfacl !

Können zusätzlich zu UVMM Details zur Virtualisierung per qemu/kvm im UCS-System eingestellt werden?

Zum Beispiel per (sowas wie):

qemu-kvm -bios …

oder direkt in den Definitionen:


<driver name=‘qemu’ type=‘raw’ cache=‘writeback’/>
<target dev=’…’ bus=‘sata’/>
<address type=‘drive’ controller=‘0’ bus=‘0’ target=‘0’ unit=‘2’/>

Ich will nicht mit der UCR (oder anderen Konstrukten, die ich noch nicht kenne) in Konflikt kommen, indem ich voreilig manuell an Konfigurationen herum fummle.

Da die Installation von pfSense jetzt hängt wie - bei mir - das Windows 2016 und ich zu dem betreffenden “BTX halted”-Fehler bei pfSense viel zu AHCI/SATA und anderen BIOS-Einstellungen finde, denke ich, dass sich ggf. beide meiner boot-Hänger mit feineren Einstellungen der virtuellen Maschinen ggf. beheben lassen könnten.

Wobei ich noch erwähnen möchte, dass beide Anzeigen zur CPU-Auslastung der im Boot hängenden virtuellen Maschinen dauerhaft bei 100% kleben, was aber weder an der Performance des UCS-Servers selbst, noch der laufenden, virtuellen ubuntu-Desktop-Installation bemerkt werden kann.

Mastodon