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!
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…
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
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.
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?
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
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 !
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.
