Wie vorgehen? Netcup Windows Server 2016 Snapshot auf heimischem PC in Virtualisierungssoftware einbinden.

  • Hallo zusammen,


    ich starte mal mit folgendem Netcup Wiki Zitat, denn darum geht es bei mir.


    "Auch lassen sich "Offline Snapshots" exportieren, wodurch Sie ein komplettes Abbild Ihres Servers herunterladen und so z. B. auf Ihrem heimischen PC in eine Virtualisierungssoftware einbinden können, um eine große Änderung vorab zu testen." (Und dann auch wieder zurückspielen)

    Soweit bin ich:

    1) Habe ein Offline Snapshot von meinem netcup VPS 1000G8 erstellt. Das Image (QCOW2) habe nun auch Local vorliegen. Hierbei handelt es um einen Windows Server 2016 mit diversen Hardware gebundenen Lizenzen. Läuft seit Monaten Top!!!
    2) Workstation mit 2x 6 XEON Cores und 24 GB Ram steht hier unterm Schriebtisch. Mit frischen Ubuntu, KVM und virt Manager. Ich kann auch gerne jedes andere OS installieren.

    3) Mein Snapshot mit Hilfe des virt Managers eingebunden und gestartet. (einfach durchgeklickt, habe von den Konfigurationmöglichkeit nicht wirklich Ahnung)

    4) Windows Server startet ohne grosse Probleme. Im Geräte Manager gibt es nun diverse Ausrufezeichen und meine Lizenzen werden nicht anerkannt. Windows ist nicht mehr aktiviert ach und und und und.


    Meine Frage:

    Wie bekomme ich den Offline Snapshoot in meinem Localem System 1:1 (!!!) zum laufen? - Meine Kenntnisse in Sachen Linux, KVM, Befehlszeilen &&& sind hier Anfängerniveau.


    Ich habe den Eindruck, das mir eine Art KVM Hardwarekonfiguraton fehlt? Sprich die von Netcup. Hypervisor? So steht in der Regedit des Live Windows Servers etwas von Seabios, Local dann was anderes ach &&&


    Wie geh ich nun am besten weiter vor? Schon mal herzlich Dank fürs lesen und evt Antworten :)


    Berg

  • Hallo,

    hier ist halt die Frage wie empfindlich von wegen "Hardwareänderung" diverse Lizenzen sind ...

    es gibt x "Angriffspunkte"


    - virtuelle Platte: hat diese die selbe Größe, die selbe Schnittstelle, ...

    - virtuelles RAM: hat dieses die selbe Größe

    - virtuelle CPU: passt diese? die selbe Anzahl an Cores? ...

    - virtuelles Netzwerkinterface: hat diese die gleiche MAC-Adresse?


    werden die virt. Hardwarekomponenten mit den selben Treibern angesprochen?

    Grüße / Greetings

    Walter H.


    RS 1000 SAS G7SE / RS 500 SAS G8 / VPS 100 G7SE / RS 2000 SAS Ostern 2018

  • Hay,

    und meine Lizenzen werden nicht anerkannt. Windows ist nicht mehr aktiviert ach und und und und.

    daran wirst Du ohne neue Lizenz nichts ändern können. Problem dabei - wenn Du die geplanten Änderungen durchführst und dann wieder auf Netcup exportierst, werden diese neuen Lizenzen dann dort wahrscheinlich ebenfalls nicht mehr funktionieren. Und ob die alte sich dort wieder reaktivieren lässt hängt ein bißchen von der Quelle ab - wenn es ein günstig gekaufter Volumenkey war, dann kann es sein, dass der abgedreht wurde. Wenn offiziell teuer von MS-Händler erworben... wahrscheinlich ohne Probleme. Du könntest Dich mit der Lizenzfrage natürlich auch an MS direkt wenden. Die konnten mir zu Lizenzfragen immer kompetent Antworten geben (wenn auch zu nichts anderem).


    Was die Treiber anbetrifft - ich hatte es umgekehrt, habe eine (bootfähige) vhdx von einem Kunden bekommen (die lokal nach etwas Aufwand mit den eigenen Virtualbox-Treibern lauffähig war), die auf meinen Server musste, aber Treiber für KVM waren keine drauf (bluescreen auf dem Server). Also habe ich hier lokal die vhdx in meiner virtuelle Maschine die passenden Treiber von der virtiio-CD aus dem SCP heruntergeladen und inijeziert und dann liefs auch nach dem upload auf dem Server wieder.


    Allerdings hatte ich eine Lizenz, die sich automatisch auf dem jeweiligen Server aktivieren ließ und jeweils die anderen Instanzen deaktivierte.


    CU, Peter

  • - virtuelles Netzwerkinterface: hat diese die gleiche MAC-Adresse?

    werden die virt. Hardwarekomponenten mit den selben Treibern angesprochen?

    bzgl MAC Adresse schau ich mal nach .. Danke!


    Der Rest wurde quasi gleich angelegt... lediglich die Ghz der CPU sind leicht unterschiedlich und es fehlen wohl treiber. Sollte aber kein Problem sein, da ich eine vergleichbare konfiguration mit Virtualbox fahre. Hier kann ich wunderbar das Virtualbox Image von Rechner zu Rechner (MACs) kopieren und alles funktioniert. Selbst wenn die CPU eine andere ist, der Arbeitsspeicher wesentlich kleiner und die Festplattengröße des Image sich ändert.


    Dachte das wird so laufen wie bei Virtualbox... :(

  • Hay,

    daran wirst Du ohne neue Lizenz nichts ändern können. Problem dabei - wenn Du die geplanten Änderungen durchführst und dann wieder auf Netcup exportierst, werden diese neuen Lizenzen dann dort wahrscheinlich ebenfalls nicht mehr funktionieren.

    Das befürchte ich auch .. :)


    da der Netcup Snapshoot, ohne Lizenz Probleme quasi als Dublette in einem weiteren Netcup Account läuft, dachte ich das wird dannn auf ner Workstation ebenfalls möglich sein. Bin vor 2 Monaten mit einem Windows 2012 KVM Snapshot von New York auf eine Londoner Server gezogen, auch kein Problem (hat der VPS Anbieter geregelt). Alles lief...
    Meine Erfahrungen mit VirtualBox (wie oben beschrieben), waren auch immer positive, also ohne Lizenzprobleme.

    Dachte die Hardware wird in der KVM quasi emoliert, und das war es dann.


    hier wird noch was beschrieben....

    https://serverfault.com/questi…orrect-way-to-move-kvm-vm


    Werde morgen nochmal alles incl MAC adresse durchtesten, evt. passt es dann ja. Danke schon mal....

  • Dachte die Hardware wird in der KVM quasi emoliert, und das war es dann.

    Ja, nur dass du da verschiedenste Hardware emulieren kannst. Bei den Root-Servern steht die CPU auf "Host-passthrough" bei den VPS ist es eine virtuelle CPU.

    Wenn man eine Domain XML von beiden mal vergleicht fällt auf: Es fehlt der CPU Tag bei den virtuellen CPUs.


    Gib mal bei dir sudo virsh edit name-der-vm ein und suche nach dem CPU Tag, und entferne ihn. Bei mir sieht der CPU Tag so aus:

    Code
    1. <cpu mode='host-passthrough'>
    2. <topology sockets='1' cores='4' threads='1'/>
    3. </cpu>

    Unterhalb von "Features".


    Den Tag vcpu <vcpu placement='static'>4</vcpu> lässt du intakt und passt nur die Kernanzahl an.

    Habe das Vorgehen nicht getestet - kopiere dir also deinen CPU Tag einmal weg.


    Edit:

    Und wenn du schonmal dabei bist: <emulator>/usr/bin/qemu-system-x86_64</emulator> macht dir mehr Freude als qemu-kvm-spice ;-)

  • Es klappt nun - :), also es läuft jetzt alles incl. Lizenen auf meiner Workstation.


    Hierzu habe ich das Netcup qcow2 Snapshot mit SCSI Festplattenbus eingebunden, mit der Option Hypervisor Standard. Nicht als IDE, bzw so wie es vom virt-manager angelegt wurde, die habe ich dann gelöscht. Ebsno wurde ein Eintrag zur Audio/Sound Hardware gelöscht.


    Zudem fehlte bei mir wohl eine BIOs/Firmware? Habe diesen Befehl im Vorfeld ausgeführt:

    sudo apt-get install virt-manager libvirt-daemon ovmf

    https://wiki.ubuntu.com/UEFI/OVMF


    Das Image habe ich bisher nur noch nicht auf netcup zurückgespielt. Das versuche ich mal in der nächtsen Woche.


    Danke für Euren Input....

  • Habe die letzen Tage das Einbinden des Netcup Image auf meine Localen Server noch einige mal wiederholt.


    Fazit: Es scheint lediglich der richtige Festplattencontroller eine Rolle gespielt zu haben. In meinem Fall das Einbinden als SCSI.
    Das Bios, Anzahl der Kerne, Arbeitspeicher, Art der Kerne waren egal.


    Falls es jemaden interessiert: Ich habe von einem anderen Server (kein Netcup) das Windows System mit dem Programm Drivesnapshot gesichert. Tolles, smartes Programm für alle Arten von Windows Partitionen.

    http://www.drivesnapshot.de/


    Die Sicherungsdateien dann downgeloaded und local in KVM installiert. Klappt auch hervorragend, natürlich mit der entsprechenden Konfiguration, die ja im Gerätemanager der VPS abzulesen sind.


    Bis dahin & VG!

  • ich meine mal gehört zu haben dass bis zu 4 Dinge sich verändern können, ohne daß nach neuer Lizenz geraunzt wird; (galt zu WinXP Zeiten)

    von daher scheint mir das mit dem Festplattencontroller logisch, wenn dieser das ganze ins Rollen bringt;


    eine Netzwerkkarte tauscht man schnell mal aus

    ein BIOS flasht man auch ganz schnell - gibt sogar Schadsoftware, welche die Hardware unbrauchbar machen

    RAM Riegel tauscht man auch relativ schnell

    auch ist eine CPU relativ schnell getauscht

    aber die Festplattenarchitektur,

    die tauscht man eben nicht ganz so einfach ...

    Grüße / Greetings

    Walter H.


    RS 1000 SAS G7SE / RS 500 SAS G8 / VPS 100 G7SE / RS 2000 SAS Ostern 2018

  • Die Microsoft Windows Produkt-Aktivierung ist insofern "Black-Magic", als Microsoft nicht offiziell bekanntgibt, wie die Berechnung der Prüfsummen und die zulässigen Abweichungen / Tresholds konkret wirken. Microsoft ändert diese Metriken auch laufend, um unerwünschte Re-Aktivierung nach regulärem Update/Aufrüstung zu vermeiden, und dennoch den Transfer des Systems auf andere Hardware ohne Neu-Aktivierung zu unterbinden.


    Folgende Hardware-Eigenschaften gehen (soweit bekannt) in die Prüfung mit ein:

    • System-Informationen aus den DMI-Daten (System-Hersteller, Seriennummer etc...)
    • Lizenz-Informationen aus den ACPI-Tabellen (Software Licensing Description Table) des BIOS - insbesondere bei OEM-Lizenzen!
    • Grafikkarte
    • SCSI, SAS, IDE, SATA Adapter
    • MAC-Adresse des Netzwerkadapters
    • Hauptspeicher
    • Processor Type und Serial Number
    • Harddisk sowie Volume-SerialNumber

    Nur "interne" Geräte werden in die Prüfung mit einbezogen, USB-Geräte und externe Peripherie (z.B. in Docking-Stations) wird nicht berücksichtigt. Ziel von Microsoft ist wie gesagt einerseits typische Hardware-Upgrades wie Hauptspeicher-Erweiterung, zusätzliche Disk ergänzen, Grafikkarte austauschen, ... zuzulassen, aber dennoch zu verhindern, dass das System 1:1 auf ein anderes (ähnliches) System kopiert wird ohne eine ReAktivierung zu erfordern. Der Algorithmus ist - ohne ihn zu kennen - nicht wirklich empirisch nachvollziehbar.


    Dass beim Transfer eines Image von einem virtuellen System auf ein anderes die ReAktivierung erfahrungsgemäß sehr konsequent nötig ist, legt den Verdacht nahe, dass Microsoft das durchaus bewusst so forciert. Je nach Virtualisierungsprodukt kann man all diese geprüften Merkmale mehr oder weniger gut "verstecken" bzw. am Zielsystem gleichartig emulieren. Dass das OS auf virtueller Hardware läuft ist ja einfach prüfbar, erfahrungsgemäß reicht auf virtualisierten Systemen bereits der Wechsel der Netzwerk-MAC-Adresse und/oder der CPU aus um eine ReAktivierung zu benötigen (selbst wenn alle anderen Eigenschaften gleich bleiben). Wenn man nicht mit virtuellen CPUs arbeitet, sondern die nativen Virtualisierungseigenschaften möglichst effizient nutzen möchte und so die physischen CPUs durchreicht scheitert man hier erfahrungsgemäß und es kommt jedenfalls zu einer Neu-Aktivierung.


    Im Unternehmensumfeld stellt das typischerweise kein Problem dar, da dort die Systeme mittels KeyManagementServices (KMS) und Volumenslizenzen automatisch reaktiviert werden. Auch in der Azure-Cloud muss man sich nicht darum kümmern, da dort KMS-Services bereitstehen.


    Eine 1:1 Kopie die man lediglich erstellt um mit der Kopie z.B. ein Softwareupdate zu testen, bevor man dies am Produktivsystem anwendet würde ich einfach vorübergehend ohne Aktivierung nutzen (es ist innerhalb der Grace-Periode mit keinen Einschränkungen zu rechnen).


    Ein Verschieben einer VM auf neue Hardware löst zwar eventuell eine Re-Aktivierung aus, diese kann und darf jedoch durchgeführt werden da es sich ja nicht um ein dupliziertes sondern verschobenes System handelt. Nötigenfalls (wenn die online-Aktivierung verweigert wird) muss man eben telefonisch reaktivieren und eventuell auch mit einem "Menschen" an der Aktivierungshotline sprechen, der sich das Szenario schildern lässt und bei Glaubwürdigkeit beurteilt, dass dies zulässig ist.