Bin gespannt, wie lange es dauert, bis Hyper-V auch nur noch als SaaS vertrieben wird. Der proprietäre Markt mag technisch die "einfachere" Umsetzung bieten und auch "kundennäher" sein, aber Du steuerst m.E. von einer Unischerheit in die nächste.
Bin gespannt, wie lange es dauert, bis Hyper-V auch nur noch als SaaS vertrieben wird. Der proprietäre Markt mag technisch die "einfachere" Umsetzung bieten und auch "kundennäher" sein, aber Du steuerst m.E. von einer Unischerheit in die nächste.
Im Prinzip ist bereits Oracle diesen Weg gegangen und hat den Vertrieb von Solaris nahezu eingestellt. Auch Apple hat "Computer" aus dem Nemen gestrichen und lebt eher vom appstore. Je weniger es sich aber um einen Nichenmarkt handelt, desto länger laufen "etablierte" Lösungen.
ESXi, Proxmox und Hyper-V vor Ort wird es sicher noch lange geben auch wenn MS alle auf *365 drängt.
ESXi, Proxmox und Hyper-V vor Ort wird es sicher noch lange geben auch wenn MS alle auf *365 drängt.
Luckysh0t
Enthusiast
Wenn sie es sich noch leisten können, bzw. überhaupt bei jemanden abonnieren dürfen. Wir schauen uns aktuell auch andere Produkte an, da wir noch nicht genau wissen, ob und wie es bei uns mit VMware weitergehen kann/darf, auch wenn der Aufwand enorm sein wird...das steht außer Frage.
@gea Bin kein Business-Experte, aber ein laienhafter feature-Vergleich zwischen Azure-Hypervisor und Hyper-V (Entscheider hören „infinite scalability“ und „fully managed“!), die gehypte Hybrid“Lösung“ mit Azure HCI … das schiebt den Anreiz deutlich Richtung Cloud; ich glaub deswegen nicht dran, dass MS in dem Bereich mit on-prem-Produkten noch _großes_ Geschäft machen will, das noch lange mit Parallelangeboten und „Testlizenzen“ angeschoben werden „muss“. Zuletzt werden sie wie Broadcom die (im Sinne des lock-in’s zunächst hilfreiche) Kannibalisierung schlicht beenden.
Wie gesagt: Ich bleibe gespannt, ob Hyper-V am Ende das Produkt sein wird, das übrig bleibt.
(Und ich hoffe sehr, dass das VMware-Desaster der einen oder anderen OSS-Alternative einen Schub gibt.)
Wie gesagt: Ich bleibe gespannt, ob Hyper-V am Ende das Produkt sein wird, das übrig bleibt.
(Und ich hoffe sehr, dass das VMware-Desaster der einen oder anderen OSS-Alternative einen Schub gibt.)
Jenachdem was ihr für Produkte von vmware eingesetzte habt, ändert sich nix, bzw. im Fall kleine Firma aber vSAN im Einsatz, explodiert der Preis.
Die klassischen Standard/Enterprise Plus Kunden müssen etwas tiefer in die Taschen greifen, "mehr" aber auch nicht.
Die klassischen Standard/Enterprise Plus Kunden müssen etwas tiefer in die Taschen greifen, "mehr" aber auch nicht.
AliManali
cpt sunday flyer
Hi
Habe einen ESXi napp-it AiO. Da dran hängen per NFS zwei Gäste, beide recht identisch ausgestattet. Die liegen auch auf der selben Datacenter SSD (SM883). Wenn ich nun da was entpacke (der Vorgang ist bei beiden Gästen relativ fix), braucht der anschliessende Kopiervorgang auf einem Gast < 3 min, beim anderen ~ 10 min. Geht um 5 GB Windows Updates.
Auf der 2 TB SSD sind neben der Reservierung noch ca. 180 GB frei. Die ganzen VMDK sind alle thin, denke es hängt irgendwie damit zusammen. Kann ich die SSD irgendwie trimmen, damit das besser wird? Oder sonst was tun? Liegt allerdings grad bisschen Last auf dem Host an. Aber in der einen VM geht es beim Kopiervorgang nach dem entpacken halt auf 10 MB/s runter.
Wie kommt da so ein Unterschied zustande?
Habe einen ESXi napp-it AiO. Da dran hängen per NFS zwei Gäste, beide recht identisch ausgestattet. Die liegen auch auf der selben Datacenter SSD (SM883). Wenn ich nun da was entpacke (der Vorgang ist bei beiden Gästen relativ fix), braucht der anschliessende Kopiervorgang auf einem Gast < 3 min, beim anderen ~ 10 min. Geht um 5 GB Windows Updates.
Auf der 2 TB SSD sind neben der Reservierung noch ca. 180 GB frei. Die ganzen VMDK sind alle thin, denke es hängt irgendwie damit zusammen. Kann ich die SSD irgendwie trimmen, damit das besser wird? Oder sonst was tun? Liegt allerdings grad bisschen Last auf dem Host an. Aber in der einen VM geht es beim Kopiervorgang nach dem entpacken halt auf 10 MB/s runter.
Wie kommt da so ein Unterschied zustande?
Zuletzt bearbeitet:
Luckysh0t
Enthusiast
Wir sind SPLA Kunden, daher ist das nochmal anders gelagert.
Wenn es sich um das gleiche NFS Share handelt, ist thin wohl die Ursache. Wie man das beschleunigen könnte, wäre eher eine Frage im ESXi Forum.
Hätte da mal eine grundlegende Frage:
Ich habe mein Proxmox verschlüsselt (siehe hier). Dabei wird das Boot-Laufwerk mit einer passphrase verschlüsselt, die man eintippen muss und das data laufwerk, mit einem keyfile, welches ich auf dem boot-Laufwerk platziere. So kann nach dem eintippen alles automatisch eingehängt werden.
Nun möchte ich eine möglichst stressfreie Backup-Prozedur etablieren. Natürlich geht das unter Proxmox mit Bordmitteln, aber in den Backups sind natürlich die Mapped-Laufwerke der LXC-Container nicht mit dabei, weil die ja Verzeichnisse auf dem Host repräsentieren.
Jetzt ginge das natürlich schön über die ZFS tools und ich habe mit folgendem mal ein Full-Backup gemacht:
Das klappt auch super. Jetzt hätte ich aber gerne für die Zukunft ein inkrementelles Backup der Snapshots, die seit dem letzten dazu gekommen sind um Zeit zu sparen.
Lässt sich sowas machen, ohne die passphrase einzutippen bzw. den key des Hauptpools für das externe Laufwerk zu laden?
Oder welche Strategien könnte ich sonst anwenden um das ZFS Backup inkrementell zu gestalten?
Ich habe mein Proxmox verschlüsselt (siehe hier). Dabei wird das Boot-Laufwerk mit einer passphrase verschlüsselt, die man eintippen muss und das data laufwerk, mit einem keyfile, welches ich auf dem boot-Laufwerk platziere. So kann nach dem eintippen alles automatisch eingehängt werden.
Nun möchte ich eine möglichst stressfreie Backup-Prozedur etablieren. Natürlich geht das unter Proxmox mit Bordmitteln, aber in den Backups sind natürlich die Mapped-Laufwerke der LXC-Container nicht mit dabei, weil die ja Verzeichnisse auf dem Host repräsentieren.
Jetzt ginge das natürlich schön über die ZFS tools und ich habe mit folgendem mal ein Full-Backup gemacht:
Code:
# externe festplatte über usb
zpool create -f rpoolbak /dev/sdb
# snapshot erstellen
zfs snapshot -r "rpool@backup-2024-01-19"
# aktuellen snapshot rekursiv und raw (da verschlüsselt) an die externe Platte senden
# das eingeschobene pv dient nur dazu, den Fortschritt zu überwachen
zfs send -R --raw rpool@backup-2024-01-19 | pv | zfs recv -Fdu rpoolbakDas klappt auch super. Jetzt hätte ich aber gerne für die Zukunft ein inkrementelles Backup der Snapshots, die seit dem letzten dazu gekommen sind um Zeit zu sparen.
Lässt sich sowas machen, ohne die passphrase einzutippen bzw. den key des Hauptpools für das externe Laufwerk zu laden?
Oder welche Strategien könnte ich sonst anwenden um das ZFS Backup inkrementell zu gestalten?
Release Notes for OmniOS v11 r151048o (2024-02-15)
Release Notes
illumos based server OS with ZFS, DTrace, Crossbow, SMF, Bhyve, KVM and Linux zone support
omnios.org
Security Fixes
- curl updated to version 8.6.0 fixingCVE-2024-0853.
- libxml2 updated to version 2.11.7, fixingCVE-2024-25062.
Other Changes
- The ena network driver has received a number of fixes that make it morestable in recent AWS EC2 instance types.
- Some improvements to PCI enumeration under BIOS boot as AWS EC2 guest havebeen integrated.
- Timezone data has been updated to version 2024a.
pwnbert
Enthusiast
- Mitglied seit
- 30.10.2014
- Beiträge
- 3.633
Ich weiss, die Frage ist jetzt vielleicht recht blöd, aber...
... was sind in der Regel eigenltich sync writes und async writes?
Also ich versteh den Unterschied, wegen ZIL und SLOG und so...
Aber welche Vorgänge, so in "unserem" Alltag sind nun was?
... was sind in der Regel eigenltich sync writes und async writes?
Also ich versteh den Unterschied, wegen ZIL und SLOG und so...
Aber welche Vorgänge, so in "unserem" Alltag sind nun was?
Grundsätzlich schreibt ZFS immer asyncron. Writes werden im Ramcache gesammelt und dann verzögert und in Schüben alle paar Sekunden als größere schnelle Blöcke geschrieben um einzelne, kleine, langsame Schreibaktionen zu vermeiden.
Weil damit bei einem Absturz mehrere Sekunden der im RAM gesammelte Writes verloren gehen können, kann man per Dateisystem sync write aktivieren. Dadurch wird ZUSÄTZLICH eine Protokollierung aller bestätigten Schreibvorgänge auf den schnellen ZIL Bereich des Pools oder auf eine Slog Platte aktiviert. Stürzt der Rechner ab, werden fehlende aber bestätigte Writes beim nächsten Reboot nachgeholt. Sync write ist wegen der kleinen sync writes sehr langsam. Zudem muss ja alles doppelt geschrieben werden. Sync nutzt man daher nur wenn mans absolut braucht.
Da ZFS wegen Copy on Write nicht kaputtgeht, wird sync logging bei einem reinen Filer egal ob NFS oder SMB auch nicht benötigt. Hat man jedoch Transaktionen oder z.B. VMs mit Gastdateisystemen, so kann ZFS die im Crashfall nicht schützen.. In dem Fall aktiviert man sync.
Sync Einstellungen sind always, disabled und default. Bei default kann das schreibende Programm selbst entscheiden. ESXi + NFS ist dann sync, SMB async.
Weil damit bei einem Absturz mehrere Sekunden der im RAM gesammelte Writes verloren gehen können, kann man per Dateisystem sync write aktivieren. Dadurch wird ZUSÄTZLICH eine Protokollierung aller bestätigten Schreibvorgänge auf den schnellen ZIL Bereich des Pools oder auf eine Slog Platte aktiviert. Stürzt der Rechner ab, werden fehlende aber bestätigte Writes beim nächsten Reboot nachgeholt. Sync write ist wegen der kleinen sync writes sehr langsam. Zudem muss ja alles doppelt geschrieben werden. Sync nutzt man daher nur wenn mans absolut braucht.
Da ZFS wegen Copy on Write nicht kaputtgeht, wird sync logging bei einem reinen Filer egal ob NFS oder SMB auch nicht benötigt. Hat man jedoch Transaktionen oder z.B. VMs mit Gastdateisystemen, so kann ZFS die im Crashfall nicht schützen.. In dem Fall aktiviert man sync.
Sync Einstellungen sind always, disabled und default. Bei default kann das schreibende Programm selbst entscheiden. ESXi + NFS ist dann sync, SMB async.
Zuletzt bearbeitet:
pwnbert
Enthusiast
- Mitglied seit
- 30.10.2014
- Beiträge
- 3.633
Danke.
Weisst du, was der QEMU Host default hat?
Wie läuft denn das, wenn da jetzt eine VM läuft, die keinen Datenträger direkt durchgereicht hat, sondern "in dem lebt, was ihr der Host (vom Scale) gegeben hat"?
Zählt dann das äußere Dateisystem, das innere, beide? Sofern es sowas gibt bzw. sofern man das so nennen kann.
Wenn das Gastsystem dann auch ein cow FS verwendet, reicht das prinzipiell?
LG
Weisst du, was der QEMU Host default hat?
Wie läuft denn das, wenn da jetzt eine VM läuft, die keinen Datenträger direkt durchgereicht hat, sondern "in dem lebt, was ihr der Host (vom Scale) gegeben hat"?
Zählt dann das äußere Dateisystem, das innere, beide? Sofern es sowas gibt bzw. sofern man das so nennen kann.
Wenn das Gastsystem dann auch ein cow FS verwendet, reicht das prinzipiell?
LG
Nein .
Betrachten wir mal eine atomare Schreibaktion bei der eine kleine Textnotiz aus Word auf einen SMB Filer geschrieben wird, Dabei landet zuerst ein 4K Datenblock auf dem Pool, anchließend werden die zugehörigen Metadaten in einem zweiten Schritt aktualisiert. Stürzt der Rechner nach ersterem und vor zweiterem ab (oder wird da ein Snap gemacht), so wird die ganze Aktion ignoriert und auf dem Pool bleibt der Datenstand vor der Aktion gültig. ZFS hat ja volle Kontrolle was passiert. Word muss sich selber per tmp File darum kümmern dass man die Aktion wiederholen kann.
Hat man jetzt Word in einer VM ist der Ablauf der gleiche. Stürzt jetzt aber der Rechner nach 1. und vor 2. ab (oder man macht gerade da einen Snap im darunterligenden ZFS Dateisystem) so kann es passieren dass im Gastdateisytem ein halbfertiger Schreibvorgang stattgefunden hat. ZFS würde sich da in der VM auch unkritischer verhalten, Sync write dafür sorgen dass bestätigte Schreibvorgänge mit ext4/ntfs auf dem Gastdateisystem nach Reboot nachgeholt werden und damit die Gefahr eines korrupten Gastdateisystems stark verringert wird.
Halt alles eine Frage des Timings und damit Statistik. Ist man Gustav Gans geht das immer gut. Ist man der Pechvogel geht das mein ersten Vorfall voll in die Hose und das Gast Dateisystem korrupt. Mit VM Storage ist damit sync write Vorraussetzung für sicheren Betrieb. Wenn man unsicher ist, ob ein bestimmtes System mit der default Einstellung sync macht, stellt man das Dateisystem auf always.
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 515
Klar geht das inkrementell, -I (bzw -i wenn du die Snapshots dazwischen nicht mitnehen willst) ist dein Freund!
Also
zfs send -RI --raw rpool@alterSnap rpool@neuerSnap | pv | zfs recv -Fdu rpoolbak
Da du --raw (-w) sendest braucht der Key auch nirgends geladen sein.
cu
Ja hervorragend, vielen Dank. Ich dachte nicht, dass die Metadaten der Snapshots auch im verschlüsselten Modus zur Verfügung stehen und via `--raw` übertragen werden können. ZFS ist einfach unschlagbar
Damit ist mein Backup-Problem gelöst.the_pi_man
Enthusiast
Das Problem ist, dass ich den Pool (Solaris) ja gar nicht erst importiert bekomme. Trotzdem erkennt er wohl irgendwie, das die 7 Platten mal ein Pool waren (über Metadateien?).
Der Screenshot ist wenn ich in napp-it auf den Punkt "Pool importieren" gehe. Normalerweise ist ja bei einem Exportierten Pool, dann als erste Zeile immer die id+name des Pools. Dort wird aber momentan ga nichts angezeigt und in der zweiten Zeile kann ich den Namen des (neuen) Pools angeben. Und egal ob ich den Pool gleich mounte oder nicht, es erscheint immer die Fehlermeldung "Ups... geht nicht"
Auf dem jetzt aktuellen System (ESXi mit einer VM "Solaris 11.4.42.111) hatte ich den Pool noch nie importiert. Daher wird es wohl das Cache-File auch (noch) nicht geben.
forum.proxmox.com
ich bin mir aber unsicher wie ich die Aussagen auf den beiden Seiten deuten soll...
Der Screenshot ist wenn ich in napp-it auf den Punkt "Pool importieren" gehe. Normalerweise ist ja bei einem Exportierten Pool, dann als erste Zeile immer die id+name des Pools. Dort wird aber momentan ga nichts angezeigt und in der zweiten Zeile kann ich den Namen des (neuen) Pools angeben. Und egal ob ich den Pool gleich mounte oder nicht, es erscheint immer die Fehlermeldung "Ups... geht nicht"
Auf dem jetzt aktuellen System (ESXi mit einer VM "Solaris 11.4.42.111) hatte ich den Pool noch nie importiert. Daher wird es wohl das Cache-File auch (noch) nicht geben.
[SOLVED] rpool: Mismatch between pool hostid and system hostid on imported pool
Guten Abend, es geht um die o.g. Meldung bzgl. meines rpool: # zpool status pool: rpool state: ONLINE status: Mismatch between pool hostid and system hostid on imported pool. This pool was previously imported into a system with a different hostid, and then was verbatim imported into...
forum.proxmox.com
ich bin mir aber unsicher wie ich die Aussagen auf den beiden Seiten deuten soll...
Zuletzt bearbeitet:
was zeigt denn "zpool import" bzw "zpool import -D" auf der Console.
Dabei werden alle Platten auf zfs pools untersucht. Werden Pools gefunden, kann man die mit zpool import -f poolname importieren.
Lösungen unter Linux treffen nur dann auf Solaris zu, wenn es sich um ZFS Eigenschaften und nicht OS Settings handelt.
Ist denn multihost auf dem Pool aktiviert?
Diese Pool Eigenschaft nutzt man in HA Multipath Failover Umgebungen um zu verhindern, dass ein Pool gleichzeitig von zwei Servern gemountet werden kann. Kann man durchaus testhalber mal umschalten.
Dabei werden alle Platten auf zfs pools untersucht. Werden Pools gefunden, kann man die mit zpool import -f poolname importieren.
Lösungen unter Linux treffen nur dann auf Solaris zu, wenn es sich um ZFS Eigenschaften und nicht OS Settings handelt.
Ist denn multihost auf dem Pool aktiviert?
Diese Pool Eigenschaft nutzt man in HA Multipath Failover Umgebungen um zu verhindern, dass ein Pool gleichzeitig von zwei Servern gemountet werden kann. Kann man durchaus testhalber mal umschalten.
the_pi_man
Enthusiast
Komisch, auf der Konsole hat es dann gelüppt, Evtl liegt es ja am -force.....
@gea
du bist einfach der Beste *verbeug* Ich bin einfach soooooooo
Soll ich ein
zpool upgrade
wagen?
Ich bin wirklich sooooo happy! 2 Monate Arbeit, triel & error, Angst das alles weg ist. Kosten für neue Hardware....
@gea
du bist einfach der Beste *verbeug* Ich bin einfach soooooooo
Soll ich ein
zpool upgrade
wagen?
Ich bin wirklich sooooo happy! 2 Monate Arbeit, triel & error, Angst das alles weg ist. Kosten für neue Hardware....
Zuletzt bearbeitet:
Ein Pool > Import in napp-it
- zeigt alle Pools die mit zpool import oder zpool import -D erkannt werden
- Importiert dann mit zpool import -f
Pool Upgrade:
Eine neuere ZFS Version bringt neue Features.
Eine ältere OS Version kann aber den Pool eventuell nicht mehr importieren (sollte aber egal sein).
docs.oracle.com
ps
Open-ZFS (mit features) zeigt Pool Version 5000
Damit kann Oracle noch viele Updates machen bis sich das beißt.
Open-ZFS und native Solaris ZFS sind mit Pool v28 und Filesystem v5 zueinander kompatibel
(Das ist aber der ZFS Stand von vor 10 Jahren)
- zeigt alle Pools die mit zpool import oder zpool import -D erkannt werden
- Importiert dann mit zpool import -f
Pool Upgrade:
Eine neuere ZFS Version bringt neue Features.
Eine ältere OS Version kann aber den Pool eventuell nicht mehr importieren (sollte aber egal sein).
Managing ZFS File Systems in Oracle Solaris 11.4
docs.oracle.com
ps
Open-ZFS (mit features) zeigt Pool Version 5000
Damit kann Oracle noch viele Updates machen bis sich das beißt.
Open-ZFS und native Solaris ZFS sind mit Pool v28 und Filesystem v5 zueinander kompatibel
(Das ist aber der ZFS Stand von vor 10 Jahren)
Zuletzt bearbeitet:
Ich habe in meinem RAIDZ2 ein einzelnes vdev mit 4x 12TB und 6x 14TB die 12TB-Platten durch 16er ersetzt. Einzeln mit Resilver nach jedem Tausch.
Nachdem alles fertig war, war die Anzeige der Größe noch wie zuvor, daher habe ich auf "Expand" gedrückt, was mit einem Fehler abbrach, dass sdb in Verwendung sei und man neustarten solle.
Nach dem Neustart wurde dann sda wieder als unassigned disk angezeigt, war aber im vdev trotzdem als online drin, das vdev war dennoch degraded.
Nun läuft wieder ein Resilver, um die sda wieder neu zu integrieren.
Eine Idee was da passiert ist und wie ich die Erweiterung dann erfolgreich durchführe? Ich tippe auf die Partitionen - da sind wohl ehem. Swap Paritionen drauf....
Infos:
Nachdem alles fertig war, war die Anzeige der Größe noch wie zuvor, daher habe ich auf "Expand" gedrückt, was mit einem Fehler abbrach, dass sdb in Verwendung sei und man neustarten solle.
Nach dem Neustart wurde dann sda wieder als unassigned disk angezeigt, war aber im vdev trotzdem als online drin, das vdev war dennoch degraded.
Nun läuft wieder ein Resilver, um die sda wieder neu zu integrieren.
Eine Idee was da passiert ist und wie ich die Erweiterung dann erfolgreich durchführe? Ich tippe auf die Partitionen - da sind wohl ehem. Swap Paritionen drauf....
Infos:
Version:
TrueNAS-SCALE-23.10.1.3
TrueNAS-SCALE-23.10.1.3
Code:
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
Daten 109T 91.5T 17.6T - - 0% 83% 1.00x DEGRADED /mnt
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 14.6T 0 disk
└─sda1 8:1 0 10.9T 0 part
sdb 8:16 0 14.6T 0 disk
└─sdb1 8:17 0 10.9T 0 part
sdc 8:32 0 14.6T 0 disk
└─sdc1 8:33 0 10.9T 0 part
sdd 8:48 0 14.6T 0 disk
└─sdd1 8:49 0 10.9T 0 part
sde 8:64 0 12.7T 0 disk
├─sde1 8:65 0 2G 0 part
└─sde2 8:66 0 12.7T 0 part
sdf 8:80 0 12.7T 0 disk
├─sdf1 8:81 0 2G 0 part
└─sdf2 8:82 0 12.7T 0 part
sdg 8:96 0 12.7T 0 disk
├─sdg1 8:97 0 2G 0 part
└─sdg2 8:98 0 12.7T 0 part
sdh 8:112 0 12.7T 0 disk
├─sdh1 8:113 0 2G 0 part
└─sdh2 8:114 0 12.7T 0 part
sdi 8:128 0 12.7T 0 disk
├─sdi1 8:129 0 2G 0 part
└─sdi2 8:130 0 12.7T 0 part
sdk 8:160 0 12.7T 0 disk
├─sdk1 8:161 0 2G 0 part
└─sdk2 8:162 0 12.7T 0 part
Zuletzt bearbeitet:
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 702
Spiele mit dem Gedanken eine Intel P1600X Optane M.2 für Proxmox als Bootdrive UND VM Storage zu nehmen.
Dort
www.thomas-krenn.com
steht aber "Einsatz mit VMware (als Bootdrive, nicht für VSAN)" was mich verwirrt. Was sprich dagegen auf dieser SSD auch VMs und Container zu betreiben?
Dort
Intel P1600X Optane M.2 NVMe SSDs – Thomas-Krenn-Wiki
Intel P1600X Optane M.2 NVMe SSDs bieten dank PCIe 3.0 x4 Schnittstelle Durchsatzraten von bis zu 1.870 MB/s. Erhältlich mit 58 GB oder 188 GB sind die SSDs als Bootdrive geeignet und für den Einsatz mit VMware (als Bootdrive, nicht für VSAN) und Microsoft Windows zertifiziert. Informationen zu...
steht aber "Einsatz mit VMware (als Bootdrive, nicht für VSAN)" was mich verwirrt. Was sprich dagegen auf dieser SSD auch VMs und Container zu betreiben?
Happy Hepo
Experte
- Mitglied seit
- 16.01.2017
- Beiträge
- 225
Meist die Größe, 188GB sind nicht viel Platz für VMs
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 702
Größe reicht bei mir
besterino
Legende
That's what she said. 
Luckysh0t
Enthusiast
Das dürfte die sein https://www.amazon.de/Intel-Optane-...e&keywords=Intel+P1600X&qid=1708498623&sr=8-2 Die habe ich auch in meinem PVE als slog device - allerdings hat die 118 GB und nicht 188 GB. Da hat TK wohl einen Schreibfehler, ich finde auch keine Version mit 188 GB.
