Windows Server 2019 auf LXD Virtualisierung
Hallo zusammen, wir haben uns von VMWare verabschiedet und haben die vmdk´s von zwei Windows Servern erfolgreich migriert und in LXD integriert. Wir haben eine HP Server mit zwei Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz CPUs, jeweils mit 10 Kernen und 48 GB RAM. Siehe Foto. Nun zu meinem Problem:
Die Migration war nicht so einfach, hat aber geklappt. Beide Windows Server laufen meist ohne Probleme, aber es kommt doch schon mal vor, das nach ein paar Tagen, beide Server extrem langsam sind. Mit extrem meine ich, dass die CMD öffnen oder die Powershell öffnen, 10 minuten braucht. Wenn ich dann einen Befehl eintippe z.B: Get-Process s*|Sort-Object cpu -Descending dauert es manchmal nochmal 20 minuten das es mir etwas anzeigt. Die beiden Server sind so konfiguriert, das ich dem wichtigen Server von uns 10 CPUs und 20 GB RAM zugewiesen habe. Dem andern 5 Kerne und 12 GB RAM, der rest ist noch für den Ubuntu Server wo das LXD drauf läuft. Dennoch habe ich oft eine Performance, als ob ich einen 386 er laufen habe mit Windows 11 drauf.
Hier mal die YAML config: name: Servername
description: ''
status: Running
status_code: 103
created_at: '2024-11-19T20:08:37.455180739Z'
last_used_at: '2025-02-14T07:23:23.883483773Z'
location: none
type: virtual-machine
project: default
architecture: x86_64
ephemeral: false
stateful: false
profiles:
- default
config:
limits.cpu: '10'
limits.memory: 20GiB
snapshots.schedule: '@weekly'
volatile.cloud-init.instance-id: nichtrelevant
volatile.eth0.host_name: nichtrelevant
volatile.eth0.hwaddr: nichtrelevant
volatile.last_state.power: RUNNING
volatile.uuid: nichtrelevant
volatile.uuid.nichtrelevant
volatile.vsock_id: 'nichtrelevant'
devices:
custom-device-name:
boot.priority: '2'
source: /home/nos-it/virtio-win-0.1.262.iso
type: disk
root:
path: /
pool: lxdstorage
size: 200GiB
type: disk
Was mir aufgefallen ist, das die Cluster Größe der Festplatte auf 4kb eingestellt ist und eigentlich bei 2MB liegen sollte. Ich habe aber weder beim Support noch im LXD Forum eine info bekommen wie ich die evtl. vergrößern könnte. Ich habe das Gefühl, das da irgendwas nicht stimmt. Wenn ich auf dem Ubuntu Server nach den ressourcen schaue, dann schläft der Server weil er kaum leistung zieht. Habt Ihr mir einen Tipp wie ich herausfinden kann, welcher Prozess oder Dienst oder was die Kiste so extrem langsam macht? Danke euch.
Die Migration war nicht so einfach, hat aber geklappt. Beide Windows Server laufen meist ohne Probleme, aber es kommt doch schon mal vor, das nach ein paar Tagen, beide Server extrem langsam sind. Mit extrem meine ich, dass die CMD öffnen oder die Powershell öffnen, 10 minuten braucht. Wenn ich dann einen Befehl eintippe z.B: Get-Process s*|Sort-Object cpu -Descending dauert es manchmal nochmal 20 minuten das es mir etwas anzeigt. Die beiden Server sind so konfiguriert, das ich dem wichtigen Server von uns 10 CPUs und 20 GB RAM zugewiesen habe. Dem andern 5 Kerne und 12 GB RAM, der rest ist noch für den Ubuntu Server wo das LXD drauf läuft. Dennoch habe ich oft eine Performance, als ob ich einen 386 er laufen habe mit Windows 11 drauf.
Hier mal die YAML config: name: Servername
description: ''
status: Running
status_code: 103
created_at: '2024-11-19T20:08:37.455180739Z'
last_used_at: '2025-02-14T07:23:23.883483773Z'
location: none
type: virtual-machine
project: default
architecture: x86_64
ephemeral: false
stateful: false
profiles:
- default
config:
limits.cpu: '10'
limits.memory: 20GiB
snapshots.schedule: '@weekly'
volatile.cloud-init.instance-id: nichtrelevant
volatile.eth0.host_name: nichtrelevant
volatile.eth0.hwaddr: nichtrelevant
volatile.last_state.power: RUNNING
volatile.uuid: nichtrelevant
volatile.uuid.nichtrelevant
volatile.vsock_id: 'nichtrelevant'
devices:
custom-device-name:
boot.priority: '2'
source: /home/nos-it/virtio-win-0.1.262.iso
type: disk
root:
path: /
pool: lxdstorage
size: 200GiB
type: disk
Was mir aufgefallen ist, das die Cluster Größe der Festplatte auf 4kb eingestellt ist und eigentlich bei 2MB liegen sollte. Ich habe aber weder beim Support noch im LXD Forum eine info bekommen wie ich die evtl. vergrößern könnte. Ich habe das Gefühl, das da irgendwas nicht stimmt. Wenn ich auf dem Ubuntu Server nach den ressourcen schaue, dann schläft der Server weil er kaum leistung zieht. Habt Ihr mir einen Tipp wie ich herausfinden kann, welcher Prozess oder Dienst oder was die Kiste so extrem langsam macht? Danke euch.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671897
Url: https://administrator.de/forum/windows-server-2019-auf-lxd-virtualisierung-671897.html
Ausgedruckt am: 12.04.2025 um 16:04 Uhr
32 Kommentare
Neuester Kommentar
Verstehe ich das richtig das du 2x 10 pCore (2x 20 pCore mit HT) hast und deine beiden dicksten VMs je 10 vCore zugewiesen bekommen haben + es gibt noch weitere VMs mit jeweils bis zu 5 vCores? War das etwa schon unter VMware so? - Kann ich mir jedenfalls nicht vorstellen.
Auch wenn ich LXD nicht kenne sollte das zu viel sein. CPU sollte man nicht zu sehr überprovisionieren. Dazu kommt, das deine CPUs schon älter (2013) und recht schmal sind. Als Erklärung kannst du dir mal das hier durchlesen:
https://nexcon.ch/hyper-v-die-ideale-anzahl-vcpus/
Das Grundprinzip ist bei allen Hypervisoren ähnlich, also Hyper-V oder ESXi ist egal. LXD wird das Rad nicht neu erfunden haben also vermutlich eher mehr Probleme mit zu dicken VMs haben als weniger.
Unter ESXi kann man das mit esxtop gut nachvollziehen. Bei dir solltest du erstmal die Kerne runter schrauben (Edit: mach mal nicht mehr als 4 oder max 6 pro VM) und beobachten, ob deine Lags noch auftreten.
Auch wenn ich LXD nicht kenne sollte das zu viel sein. CPU sollte man nicht zu sehr überprovisionieren. Dazu kommt, das deine CPUs schon älter (2013) und recht schmal sind. Als Erklärung kannst du dir mal das hier durchlesen:
https://nexcon.ch/hyper-v-die-ideale-anzahl-vcpus/
Das Grundprinzip ist bei allen Hypervisoren ähnlich, also Hyper-V oder ESXi ist egal. LXD wird das Rad nicht neu erfunden haben also vermutlich eher mehr Probleme mit zu dicken VMs haben als weniger.
Unter ESXi kann man das mit esxtop gut nachvollziehen. Bei dir solltest du erstmal die Kerne runter schrauben (Edit: mach mal nicht mehr als 4 oder max 6 pro VM) und beobachten, ob deine Lags noch auftreten.
Ich sage mal falsches Provisioning!
Die beiden Hosts haben 10Kerne. Die erste VM hat 10 Kerne zugewiesen und die zweite VM 5 Kerne.
Und wieviel Kerne bleiben dem Host? - Richtig, nämlich KEINE!
Dem Host müssen schon Kerne für die Verwaltung reserviert werden!
Wie waren die VMware Hosts ausgestattet?
Wie waren dort die VMs eingerichtet?
Um welche Anwendungen handelt es sich, daß der ersten VM 10 Kerne zugewiesen sind?
[Edit Korrektur auf 10 Kerne]
Gruss Penny.
Die beiden Hosts haben 10Kerne. Die erste VM hat 10 Kerne zugewiesen und die zweite VM 5 Kerne.
Und wieviel Kerne bleiben dem Host? - Richtig, nämlich KEINE!
Dem Host müssen schon Kerne für die Verwaltung reserviert werden!
Wie waren die VMware Hosts ausgestattet?
Wie waren dort die VMs eingerichtet?
Um welche Anwendungen handelt es sich, daß der ersten VM 10 Kerne zugewiesen sind?
[Edit Korrektur auf 10 Kerne]
Gruss Penny.
Moin...
du hast das Blech völlig überbucht... CPU und RAM!
was hast du den für nen Server von HP DL380 G8 oder G9 etc?
wiso nur 48 GB RAM?
am besten du besorgst mehr RAM.. 128GB kosten bei der alten kiste auch nicht mehr die Welt, und bessere CPUs..
wenn du uns schreibst, was für nen HP Server das genau ist, sag ich dir, was für CPUs du nutzen kannst!
Frank
du hast das Blech völlig überbucht... CPU und RAM!
was hast du den für nen Server von HP DL380 G8 oder G9 etc?
wiso nur 48 GB RAM?
am besten du besorgst mehr RAM.. 128GB kosten bei der alten kiste auch nicht mehr die Welt, und bessere CPUs..
wenn du uns schreibst, was für nen HP Server das genau ist, sag ich dir, was für CPUs du nutzen kannst!
Frank
Moin...
Gruss Penny.
Frank
Zitat von @Penny.Cilin:
Ich sage mal falsches Provisioning!
Die beiden Hosts haben 10Kerne. Die erste VM hat 10 Kerne zugewiesen und die zweite VM 5 Kerne.
Und wieviel Kerne bleiben dem Host? - Richtig, nämlich KEINE!
Dem Host müssen schon Kerne für die Verwaltung reserviert werden!
Wie waren die VMware Hosts ausgestattet?
Wie waren dort die VMs eingerichtet?
Um welche Anwendungen handelt es sich, daß der ersten VM 110 Kerne zugewiesen sind?
wo hast du das mit den 110 Kernen gelesen?Ich sage mal falsches Provisioning!
Die beiden Hosts haben 10Kerne. Die erste VM hat 10 Kerne zugewiesen und die zweite VM 5 Kerne.
Und wieviel Kerne bleiben dem Host? - Richtig, nämlich KEINE!
Dem Host müssen schon Kerne für die Verwaltung reserviert werden!
Wie waren die VMware Hosts ausgestattet?
Wie waren dort die VMs eingerichtet?
Um welche Anwendungen handelt es sich, daß der ersten VM 110 Kerne zugewiesen sind?
Gruss Penny.
Frank
Ich würde auch source: /home/nos-it/virtio-win-0.1.262.iso mal raushauen.
Gibt unter keinen Hypervisor nen Grund eine ISO gemounted zu haben die man nicht mehr braucht, schon gar nicht von einen home Verzeichnis was dann vielleicht auf einen anderen Storage liegt.
Kann etlich Stunden Fehlersuche sparen wenn man rausfinden will warum die Backups nicht funktionieren oder zu lange brauchen.
Gibt unter keinen Hypervisor nen Grund eine ISO gemounted zu haben die man nicht mehr braucht, schon gar nicht von einen home Verzeichnis was dann vielleicht auf einen anderen Storage liegt.
Kann etlich Stunden Fehlersuche sparen wenn man rausfinden will warum die Backups nicht funktionieren oder zu lange brauchen.
Zitat von @Benboocha:
Hey Leute, danke für eure Kommentare, also zunächst, ich habe 2 VMs Windows Server 2019 die einmal 10 Cores, und einmal 5 Cores haben.
Okay das hatte ich erst anders verstanden.Hey Leute, danke für eure Kommentare, also zunächst, ich habe 2 VMs Windows Server 2019 die einmal 10 Cores, und einmal 5 Cores haben.
Sind zusammen 15 von 20.
Du hast 2x E5-2670 v2 a 10 pCore ohne HT, hast du Hyperthreading ausgeschaltet?Wenn ja warum?
Sind eventuell noch Einstellungen im BIOS nicht auf maximale Performance eingestellt?
5 Cores sind frei für das Ubuntu 2404 LTS mit der LXD Virtualisierung.
Also für den Hypervisor, wenn ich richtig verstehe keine weitere VM außer den zwei.Also bitte versteht mich nicht falsch. Ich habe bei VMWare bei dem einen Server 20 Cores und 10 Cores verwendet, weil er die vCores mit genutzt hat und es lief einwandfrei.
Naja was bei VMware klappt muss bei LXD nicht zwingend genauso laufen. Ich habe etwas suchen müssen wie LXD überhaupt arbeitet und so ganz verstehe ich das immer noch nicht:LXD (LXC + LXD) provides the virtual machine experience without the virtual machines!
LXC provides an environment to run a complete Operating Systems, with all necessary services. Simply put, you can do on a LXC container what you do on a virtual machine. LXD provides Hypervisor’s management capabilities.
https://www.adaltas.com/en/2018/12/28/lxd-missing-piece/LXC provides an environment to run a complete Operating Systems, with all necessary services. Simply put, you can do on a LXC container what you do on a virtual machine. LXD provides Hypervisor’s management capabilities.
Also ESXi ist ein klassischer Typ 1 Hypervisor. LXD ist eher wie Docker aber kann auch VMs hosten, ist aber nach wie vor kein Typ 1 Hypervisor - irgendwie jedenfalls.
Also an den Cores hin oder her zu diskutieren bringt mich kein Stück an die Lösung. Es hat nichts mit der Hardware zu tun. Das kann nicht sein.
Das sehe ich nach wie vor anders. Es wird dir nicht weh tun, einfach beide VMs mal auf 4 Kerne zu setzen und eine Woche laufen zu lassen. Sind die Probleme dann noch in gleicher Form da hast du wohl recht. Aber ohne genau den Scheduler von LXD zu verstehen sagt mir mein Baugefühl nach wie vor das hier ein Problem besteht.Es muss an der VMDK (Einstellungen oder so liegen). Ich musste um die Windows kiste nutzen zu können erst die vmdk in RAW Format umwandeln.
Das scheint mir etwas abwegig. Kannst du die beiden VMs nicht mal sauber neu installieren?Ich hatte auch einen Tipp bekommen die Festplatte nicht als SCSI sondern in NVME umzustellen, habe aber noch nicht heruasgefunden wie.
Aus Performance-Sicht sicherlich interessant aber eher nicht für zeitweise auftretende, massive Lags.Auch habe ich den Tipp bekommen, das eben die Clustersize von 4 kb einfach zu klein ist.
Man kann den Server auch nach Norden ausrichten, ob das hilft?Hier geht es Null komma null um die Hardware.
Wir reden nicht von der Hardware, die ist alt aber lauffähig.Und auch die Iso ist völlig unwichtig ob die gemountet ist oder nicht.
Ja.Auch wenn die nicht gemountet ist läuft der Server heute zum Beispiel absolut reibungslos. Und die CPU wird momentan mit 4,2% in Use so gut wie kaum ausgelastet.
Die CPU aus Sicht des Hypervisors oder die CPU aus Sicht der VMs?Und vor allem, nur weil CPUs und RAM irgendwo zugewiesen sind, heisst es ja nicht das sie auch so genutzt werden. Virtualisierungen holen sich nur die Ressourcen die sie brauchen.
Nein. Du gibst der VM die Ressource x vCPUs und jedes mal, wenn die VM auch nur furzen will, reserviert sie die x vCPUs. Das habe ich Eingangs mit dem Link erklären wollen und das ist das "klassische" Typ 1 Hypervisor-Verhalten. Beim RAM mag das etwas anders sein aber CPU-Scheduling verstehen halte ich für wichtig, grade in diesem Fall.
Hi
Könntest du den drunter liegenden Storage mal etwas genauer beschreiben? Ich habe mir den Thread jetzt schon zum 2. mal durchgelesen und habe nichts genaues dazu gefunden. Größe, Anzahl, Model, RAID, Controller, Interface, Cache?
MfG
Zitat von @Benboocha:
Das Problem ist, dass ist ein Produktionsserver...das heisst, ich kann da nicht viel Testen....Wenn ich einen Test mache, dann mache ich das auf einem Laptop, der 8 Cores hat, 16 GB RAm und ne M2 SSD hat. Da läuft auch der klon des anderen Servers performance Technisch wie eine Powermaschine. Und da ist schon ein exakter Klon drauf. Was natürlich eine große Rolle spielt, ist das in dem Prod. Server nur normale HDD´s verbaut sind. Ja.....ich weiss, könnte man ersetzten, aber wir spielen grade mit dem gedanken, die Kisten in AWS Workspace zu schieben und von da aus zu verwenden. Aber es ist halt erst in der Versuchsphase.....
Das Problem ist, dass ist ein Produktionsserver...das heisst, ich kann da nicht viel Testen....Wenn ich einen Test mache, dann mache ich das auf einem Laptop, der 8 Cores hat, 16 GB RAm und ne M2 SSD hat. Da läuft auch der klon des anderen Servers performance Technisch wie eine Powermaschine. Und da ist schon ein exakter Klon drauf. Was natürlich eine große Rolle spielt, ist das in dem Prod. Server nur normale HDD´s verbaut sind. Ja.....ich weiss, könnte man ersetzten, aber wir spielen grade mit dem gedanken, die Kisten in AWS Workspace zu schieben und von da aus zu verwenden. Aber es ist halt erst in der Versuchsphase.....
Könntest du den drunter liegenden Storage mal etwas genauer beschreiben? Ich habe mir den Thread jetzt schon zum 2. mal durchgelesen und habe nichts genaues dazu gefunden. Größe, Anzahl, Model, RAID, Controller, Interface, Cache?
Zitat von @Benboocha:
Aber...wie gesagt die selbe Maschine läuft auf einem ThinkPad Laptop, mit 8 Cores und 16GB RAM, mit einer M2 SSD nicht mal im Ansatz vergleichbar. Also der HP Server arbeitet für mich wie ein 386 aus den 90 ern und der Laptop läuft wie als wäre ich im Rechenzentrum.
"Selbe Maschine" heißt die derzeitige grottige VM geklont oder eine neue Umwandlung vom Original?Aber...wie gesagt die selbe Maschine läuft auf einem ThinkPad Laptop, mit 8 Cores und 16GB RAM, mit einer M2 SSD nicht mal im Ansatz vergleichbar. Also der HP Server arbeitet für mich wie ein 386 aus den 90 ern und der Laptop läuft wie als wäre ich im Rechenzentrum.
MfG
Moin...
du meinst proxmox kostet geld ?!?!?!? machen die ne ausnahme für euch, und wollen Geld?
wat nen Blödsinn...

wenn er das will, kennt er sich mit LXD also aus, und findet den Fehler in 15 Minuten!

also mein vorschlage wäre, als erstes eine frische windows server VM zu installieren, und zu schauen, ob das genauso ist....
wenn man euch als IT-Abteilung wirklich ernst nehmen soll, würde ich ein Backup aller VMs erstellen, den kram entweder auf nen ESXI oder Proxmox schubsen... wo man weiß was rennt, und was nicht!
und nein, Proxmox kostet nix...
Frank
du meinst proxmox kostet geld ?!?!?!? machen die ne ausnahme für euch, und wollen Geld?
wat nen Blödsinn...
LXD ist genauso auf QUEMU Basis. Zumindest hat das mein IT Leiter so haben wollen.
oh... dein IT Leiter wollte das so wenn er das will, kennt er sich mit LXD also aus, und findet den Fehler in 15 Minuten!
Ich gebe dir recht, es wäre vielleicht einfacher für die Windows migration gewesen. Aber ich kann es nicht ändern....so, nun haben wir es 16 Uhr ;) wie schön das genau jetzt der Server wieder so langsam ist das keiner arbeiten kann. Ich habe alleine für den RDS login 8 minuten gebraucht. Das ist doch zum Mäuse melken.
sorry, ich möchte euch nicht zu nahe treten, aber du hast nen IT-Leiter, momentan kann keiner arbeiten, weil alles langsam ist- und ihr geht zu 100% auf ein Live System ohne es vorher zu Testen, und jetzt fängt das große wundern an... den Fehler an der sache, merkst du selber.... oder etwa nicht? also mein vorschlage wäre, als erstes eine frische windows server VM zu installieren, und zu schauen, ob das genauso ist....
wenn man euch als IT-Abteilung wirklich ernst nehmen soll, würde ich ein Backup aller VMs erstellen, den kram entweder auf nen ESXI oder Proxmox schubsen... wo man weiß was rennt, und was nicht!
und nein, Proxmox kostet nix...
Frank
Moin...
nun, ein klon nützt dir nix.... ne frische VM wäre da angebracht!
du hast 31 % CPU zeit... schon mal mit dem Prozess-Explorer nachgesehen, was da los ist?
Frank
nun, ein klon nützt dir nix.... ne frische VM wäre da angebracht!
du hast 31 % CPU zeit... schon mal mit dem Prozess-Explorer nachgesehen, was da los ist?
Frank
Zitat von @Benboocha:
Naja, kostet Geld und kann nicht mehr, ausser das es etwas einfacher ist. LXD ist genauso auf QUEMU Basis. Zumindest hat das mein IT Leiter so haben wollen. Ich gebe dir recht, es wäre vielleicht einfacher für die Windows migration gewesen. Aber ich kann es nicht ändern....so, nun haben wir es 16 Uhr ;) wie schön das genau jetzt der Server wieder so langsam ist das keiner arbeiten kann. Ich habe alleine für den RDS login 8 minuten gebraucht. Das ist doch zum Mäuse melken.
Naja, kostet Geld und kann nicht mehr, ausser das es etwas einfacher ist. LXD ist genauso auf QUEMU Basis. Zumindest hat das mein IT Leiter so haben wollen. Ich gebe dir recht, es wäre vielleicht einfacher für die Windows migration gewesen. Aber ich kann es nicht ändern....so, nun haben wir es 16 Uhr ;) wie schön das genau jetzt der Server wieder so langsam ist das keiner arbeiten kann. Ich habe alleine für den RDS login 8 minuten gebraucht. Das ist doch zum Mäuse melken.
Naja, mit 2 Win2019 Server müsstet ihr ja eine Win2019 Server lizenz haben...damit hätte man auch einen HyperV aufsetzen können und die Dinger darunter laufen lassen können.
Und Container werden doch eigentlich verwendet damit man sich Ressourcen spart in dem man Teile des darunter liegenden OS nutzt, glaub da gibts nicht viel was Windows von Ubuntu nutzen kann.
Echte VM wäre hier wohl angebrachter.
Wie ist das System aufgebaut ?
Wo liegt Ubuntu und wo der Container ?
Ist die Virtio.iso immer noch eingehängt ?
heute morgen nur schnell hingeschrieben. hier eine Erklärung:
wenn die Maschine unverändert von ESXi auf LXD verschoben wird, läuft in der VM noch ein vmxnet3 Adapter für das Netzwerk. das ist der paravirtualisierter Adapter von VMware. ein pseudo-10G-Adapter mit Treibern aus aus dem VMware Tools.
kvm/qemu arbeitet jedoch mit virtio nur so richtig flüssig. kvm kann auch E1000, E1000e und vmxnet3, aber das und besonders letzteres nicht wirklich gut.
genau das selbe Fehlerbild hatten wir bei ein paar Server 2019/2022 VMs, die 1:1 von vSphere 8 (ESXi) auf Proxmox (kvm mit virtio) umgezogen wurden: Netzwerk lief, wurde aber mit laufender Zeit immer langsamer und tröpfelte irgendwann nur noch mit ein paar Byte/S vor sich hin ... wer eine Erklärung haben will, soll mich fragen. ansonsten: einfach die virtio-treiber installieren und die adapter neu konfigurieren (auf einen virtio-Netzwerkadapter ..), MAC Adresse passend eintragen. fertig.
grundsätzlich möchte ich noch ein bisschen Senf schmieren:
1. wenn man keine Ahnung hat von den Type1 oder Type2 Hypervisor, bitte die finger davon lassen. ihr wechselt auf LXD, aber scheint kein know how in der Richtung zu haben. das ist gefährlich. und warum ausgerechnet LXD? muss es unbedingt Ubuntu sein? nehmt Proxmox mit netter GUI, das erleichtert den Umstieg ungemein. scheint ja keiner wirklich nen Plan zu haben, was er da tut. außerdem was sind das für krumme configs? 10 Threads auf ne VM? welche CPU kommt mit 5 Kernen? weiß das OS, dass es virtualisiert wurde (ist es erleuchtet? "enlightened" ???)
2. ich blase ins selbe Horn wie einige andere hier: neue VM auf dem neuen Host nach best practice anlegen und Daten und Einstellungen per Backup migrieren. Hypervisorwechsel sind möglich, wenn man weiß was man tut. ansonsten: Handbuch lesen, VM einrichten, Daten schubsen.
Er ist nicht Windows "certified", was aber nicht heißt, das Windows darauf nicht laufen kann. Ansich sollte Windows 2019 auf jeder x86 CPU laufen, ein alter X5650 bei mir ist auch "lauffähig" - nur nicht wirklich schnell.
https://learn.microsoft.com/en-us/windows-hardware/design/minimum/window ...
NOTE: The list of supported processors above does not in itself determine Microsoft support for Windows Server. The listing is a prerequisite for system certification. Only systems based on the above approved processors can be certified for Windows Server. Unless otherwise noted, Microsoft will continue to evaluate the processor list for a given OS release and update the list as new appropriate processors are available in market.
Moin,
so "kompatibel" wie deine Frage....
klar... tut es das!
Frank
so "kompatibel" wie deine Frage....
klar... tut es das!
Frank
Zitat aus dem Handbuch (https://learn.microsoft.com/en-us/windows-server/get-started/hardware-re ..)
Processor performance depends not only on the clock frequency of the processor, but also on the number of processor cores and the size of the processor cache. The following are the processor requirements.
Minimum:
1.4 GHz 64-bit processor
Compatible with x64 instruction set
Support for NX and DEP
Support for CMPXCHG16b, LAHF/SAHF, and PrefetchW instructions
Support for Second Level Address Translation (EPT or NPT)
Minimum:
1.4 GHz 64-bit processor
Compatible with x64 instruction set
Support for NX and DEP
Support for CMPXCHG16b, LAHF/SAHF, and PrefetchW instructions
Support for Second Level Address Translation (EPT or NPT)
was so ziemlich auf (fast) jede 64bit-fähige CPU zutrifft der letzten 20 Jahre... von daher: JA!
nicht zu verwechseln sind OEM-Zertifizierungen (was muss in einem Server drin sein, dass ein OEM WIndows Server $VERSION damit anbieten darf)... aber das sprengt hier den Kreis.
Thema ist eigentlich beantwortet. Warte nur auf die Rückmeldung des Threaderstellers