Virtualization Station 4.0.0.239 offiziell - kein Beta mehr

Bei meinem NAS sieht alles "normal" aus.

pasted-from-clipboard.png

Ist aber auch QTS 5.2.xxx

Danke Dir. Gut, dann ist das eine meiner kleinen unbedeutenden Eigenheiten, die sich eventuell beim nächste Update geben werden. Dass es an QTS liegt glaube ich eigentlich nicht - aber wer weiß. Vielleicht würde ja schon nochmal drüber installieren reichen.

Evtl. Zoomfaktor >100% im Browser eingestellt?

Tschau

Uwe

Nö, ist auch auf zwei Computern und sowol im eigenen Tab als auch im Fenster innerhalb QTS so.

Gerade festgestellt, dass man die VirtIO-Treiber bei der Erstellung einer Win11-VM direkt installieren kann.

Thema

Einrichtung einer Win11-VM mit der VS4 incl. VirtIO-Treiber

Gerade festgestellt, dass man die VirtIO-Treiber schon bei der Einrichtung der Win11-VM einrichten kann.

forum.qnapclub.de/wsc/attachment/41580/

forum.qnapclub.de/wsc/attachment/41581/
forum.qnapclub.de/wsc/attachment/41583/


Vor dem Start der VM folgende Einstellungen überprüfen

forum.qnapclub.de/wsc/attachment/41584/

forum.qnapclub.de/wsc/attachment/41585/

forum.qnapclub.de/wsc/attachment/41586/


Dann die VM starten

Achtung bei dem ersten Bild hat man ca. 3 Sekunden um eine Taste zu drücken

…

Becker2020

28. Mai 2024

Hallo,

ich bin gerade auf die neue Virtualization Station umgestiegen. Dabei ist mit aufgefallen das mein Ubuntu 22.04 (als EFI Version) beim booten schreibt unable to activate acpi. Das war vorher nicht so. Was aber jetzt viel schlimmer ist meine VM hat nur einen Prozessorkern, egal wie viele ich zuweise. Und beim Abschalten geht bleibt sie noch "etwas" an, d.h. es wird noch das Ubuntu Logo angezeigt und die Prozessorlast geht gegen 0 aber sie ist nicht abgeschaltet (Reboot ist hingegen kein Problem).

Meine anderen VMs werden noch über Bios gebootet, da gibt es diese Problem nicht.

Hat jemand eine Idee dazu oder ist das ein Fall für ein Ticket bei Qnap?

Ticket ist immer gut bei sowas.

...so hier noch ein kleines Update. Nach ein wenig rumprobieren hat sich gezeigt, das die "config.xml" der VM nicht richtig aktualisiert wurde. Nach dem Löschen der VM und Neuerstellung lief wieder alles wie vorher.

Aufgabe Cloning der Produktivinstanz Windows11 VM unter QTS Virtualization Station 4.0.0.239.

Ausgangslage: Funktionsfähige aktivierte Windows11 Pro Version mit HW Konfiguration CPU Intel Westmeere CPU, 32GB Speicher, KVM Hypervisor Signatur ausblenden, Gemeinsame Nutzung von Arbeitsspeicher aktivieren, UEFI & VirtIO Geräte.

Problem: Jeder absolut identische Clone (100%gleiche HW Konfiguration) macht sofort eine Windows Aktivierung notwendig obschon 100% gleiche HW verwendet wird.

Warum ist das so?
Bisher konnte ich alle aktivierten Windows Instanzen bei identischer Hardware rauf und runter klonen wie ich wollte, sofern diese nie parallel liefen. Nach der neuen Virtualization Station 4.0.0.239 scheint dies nicht mehr zu gehen. Eine Dokumentation dazu habe ich nicht gefunden, eine Erklärung oder Begründung fehlt mir. Jemand hier der das erklären kann oder eine Antwort / Begründung kennt?

Keine Ahnung woran Windows das ausmacht, aber stimmen die UUID überein? Könnte mir vorstellen dass diese herangezogen wird.

So kenne ich das auch - bereits seit Windows 10: Einige Klones gehen, irgendwann dann aber einfach nicht mehr. UUID anpassen hat meist geholfen, aber selbst das ist einmal mindestens auch fehlgeschlagen bei mir.

Ich habe meine Win11-VM unter der VS 3.6.52 am TS-364 exportiert und am TS-264 mit der VS4 importiert.

Eine erneute Aktivierung war nicht erforderlich.

Einen Export mit der VS4 werde ich in den nächsten Tagen mal testen.

Export von VMWare Systemen läuft ohne Probleme und wird sauber importiert ohne Ativierung.
Klone aus der VS4.0.0.x aktivierten Version müssen seltsamerweise aktiviert werden, UUID macht da leider keinen Unterschied bei den Windows Clients.
Es wäre echt hilfreich wenn QNAP Changes so dokumentieren würde, dass man nachvollziehen kann was warum geändert, oder ver(schlimm)bessert wurde. Teilweise nur sehr rudimentäre Infos, oder Marketing Infos über die sensationellen Neuerungen sind echt wenig hilfreich.

Nachtrag zur Windows11 Aktivierung unter VS 4.0.0.239

MS Windows führt bekanntermassen diverse Hardware Prüfungen aus, um zu ermitteln ob es signifikante HW-Änderungen an einem bereits aktivierten System gibt.

Es ist relativ schwierig eine eindeutige Aussage über Microsoft Technet o.ä, zu erhalten, welches die Indikatoren für eine HW-Änderung sind, die MS als zur zwingenden Reaktivierung relevant bewertet.

Ein wichtiger Teil der HW-Prüfung sind aber gesichert: CPU, HDD, Chipset.

Änderungen an diesen Komponenten verursachen bei abweichenden Veränderungen eine Reaktivierung bei Windows11.

Zur VS4.x

Offensichtlich hat die Virtualization Station bei dem Upgrade der Virtualisierungsumgebung, nur «Standardpfade» für Laufwerke (*.img) migriert. Das bedeutet, wenn abweichende Pfade in einer Umgebung beispielsweise auf Storage Speicherpool 1 (HDD) und Pool2 (SSD) aufgeteilt wurden, «findet» die VS nicht alle «Laufwerke» des virtualisierten Betriebssystems.

Analysiert man dann das gebootete Windows System, stellt man fest, dass die HW-Signatur der HDD (NT-Signatur) abweicht von der ursprünglichen (unmigrierten) Version.

Demzufolge muss Windows wieder aktiviert werden. Schlimmer noch, wichtige Teile der VM fehlen.

Fazit:

Die QNAP-Entwickler haben bei der Migration der VS4.x wohl standardmässig einen Pfad (Standardpfad der VM HDD) vorausgesetzt. Weicht (die HDD der VM) dieser von dem vorausgesetzten Pfad ab, fehlt dieses LW und die Signatur in der Windows HDD ist abweichend.

Tatsächlich kann man im Fehlerprotokoll lesen:

Warnung            2024-XX-XX        XX:XX:XX             ---          ---          localhost              ---          Virtualization Station     Virtual Machines              [Virtualization Station] Started virtual machine "XYZ".
Warning: There's one or more virtual disk image files that is missing.

Fügt man diese Laufwerke wieder hinzu, (Option vorhandene Laufwerke hinzufügen) laufen die VM wie erwartet, sofern diese nicht zuvor mit fehlender HDD gebootet wurden.

Heute auch bei meinem TS-364 das Update durchgeführt (Vorbereitung QTS 5.2.xx).

Alle VM (Win 11, 3 x Linux) laufen ohne Probleme.