VMware-Forum

Hallo,

auf meinem Server (OpenSuse64bit) habe ich eine VM (2560 MB Ram),welche ich in den Suspend Mode schalte. Starte ich sie kurz darauf wieder, ist sie sehr schnell wieder da (10-20 Sekunden). Starte ich allerdings den Host neu, und Resume dann die VM, dann dauert es ca 25 Minuten. Die VM geht recht flott auf 95% und da bleibt sie bis zum Schluss stehen.

Nun dachte ich, dass der Server noch etwas zu tun hat, wenn ich ihn frisch gestartet habe. Nunja, Neustart, ab in die Mittagspause und dann VM gestartet. Diesmal 35 Minuten.

Eine VM auf dem gleichen Server mit 1024 MB ist immer innerhalb von Sekunden da.

Was ist der Grund dafür?

2560MB sind ein ganz schöner Batzen. Wenn dieser komplett von Disk eingelesen werden muß, dauert es halt "etwas" länger. Der Arbeitsspeicherzustand wird ja inklusive CPU-Register eingefroren bzw in konsistenten Zustand gebracht und dann komplett auf den Datenträger geschrieben. Erst wenn dieses abgeschlossen ist, wird die VM pausiert. Wenn du also die VM nur kurz pausierst und gleich wieder aufweckst, braucht der RAM-Inhalt nicht weggeschrieben werden und die VM ist sofort wieder einsatzbereit.

Je nach VMserver-Version sind mehr als 2GB zugewiesener VM-Arbeitsspeicher auch kontraproduktiv, da dann ab einem bestimmten Wert der VM-Arbeitsspeicher durch VMware als auslagerungsfähig gekennzeichnet wird und durch das Host-OS in den virtuellen Arbeitsspeicher verlagert wird. Bei 1GB an VM-RAM ist dieser Wert bei optimaler Konfiguration auf keinen Fall schon erreicht und der VM-RAM residiert komplett im phys.RAM des Hosts. Leider brät Linux da wieder mal seine Extrawurst...

So, das Problem ist verschwunden. Ich konnte es nicht mehr nachstellen. Jegliche Speichereinstellung von 1GB bis 2,5GB brauchen nun beim resume ca. 7 bis 16s.

Ich weiß nicht,ob es am Neustart des Gasts lag, oder die Umstellung auf Preallocated Virtual Disk mit Einstellung "Optimiert für Performance".

Die Einstellung "preallocated Disk" sorgt beim Erstellen der v.HDD nur dafür, daß diese gleich in voller Größe angelegt wird und dadurch die VM wesentlich performanter wird.
Der Unterpunkt "Optimiert für Performance" aktiviert nur einen Cache, bei dem zuerst nur die Struktur und dann erst in Abhängigkeit zur CPU-Auslastung die dazugehörigen Daten geschrieben werden. Damit ist ein Datenverlust immer möglich. Die Reihenfolge könnte auch vis-versa sein, müßte ich erst nochmal genau nachsehen. Der Unterpunkt "Optimiert für Sicherheit" aktiviert eine andere Schreibstrategie, bei der Struktur und Daten immer unabhängig von der CPU-Last sofort geschrieben werden.

Ja, die Tipps habe ich hier aus dem Forum. Ich hätte zwar lieber "Optimiert für Sicherheit", allerdings habe ich extreme Performance Unterschiede bei Schreibvorgängen. Mit der Sicherheitseinstellung kam ich nur auf 1,3MB/sek. beim Kopieren einer Datei innerhalb des Laufwerks. Mit Cache und preallocated komme ich auf 12MB/sek. Naja, die Festplatte ist nicht die schnellste. Auf dem Host komme ich mit "hdparm -tT" auch gerade mal auf 40 MB/sek. Nicht die Welt, aber ich hatte gehofft, dass ich im Gast auf ähnliche Werte komme. Zu Weihnachten werde ich mir wohl ein Raid 1 mit 2 ein Terabyte Platten für die Kiste gönnen. ich hoffe dann wird alles schneller werden.

Nun, aber ich habe nicht das Gefühl, dass es mit dem langsamen Resume zusammenhängt. Oder?

Für ein langsames Resume sind in erster Linie immer die Host-HDD und danach auch die Einstellungen für die Gast-HDD verantwortlich. Wenn du in einer VM noch HDD-Werte zwischen 20-33% der ursprünglichen Host-HDD-Leistung erreichst, sei froh. Je nach CPU-Auslastung bei Host/Gast schwankt der Wert durch die vollständige VT bei VMware sehr stark.

Ein Raid1 ist da leider auch eher kontraproduktiv, wenn du keinen richtigen HDD-Controller ala Dell Perc i5/6 oder HP SmartArray sondern nur den Chipsatz-Controller (auch bekannt als Fake-Raid, Host-Raid etc) einsetzt.
Beide Teilnehmer des Raid-Verbundes müssen zwar nur die gleichen Daten schreiben, allerdings sind beide trotz der empfohlenen gleichen Ausstattung bei Anschluß, Cache, Drehzahl, Zugriffszeiten etc niemals gleich und haben Toleranzen. Dadurch sinkt die Geschwindigkeit sogar, denn erst wenn beide Platten fertig melden, gilt der Schreibvorgang für die CPU als abgeschlossen. Eine höhere Datensicherheit erreichst du eigentlich auch nur hinter einer USV oder einem Controller mit BBU. Ansonsten könnte es beim Stromausfall während des Schreibens doch zu Unterschieden zwischen den Teilnehmern kommen, die beim Host-Restart dann zu einer zeitaufwändigen Synchronisation führen. Je nach Chipsatz-Controller geschieht das entweder schon durch das Raid-Bios oder wird nach Betriebssystemstart durchgeführt. Eine Platte wird trotzdem als Master geführt und der Inhalt auf die andere (Slave) gespiegelt. Wenn eine Platte schon neuere Daten hat, wird man meistens (wie mein ICH8R) entweder vor die Wahl des neueren Inhalts (im Raid-Bios ohne Einblick in den Datenzustand besch...en zu entscheiden) gestellt oder der möglichweiser neuere, unkorrumpierte Inhalt eines Raidmitglieds wird durch den veralteten inzwischen fehlerhaften Inhalt überschrieben oder das OS versucht sich sogar am Spagat oder bietet auch eine Wahlmöglichkeit. Dadurch sind dann zwar in allen Möglichkeiten alle beteiligten Datenträger wieder konsistent und vom Inhalt gleich, trotzdem kann eine Datenkorruption durch einen unvollständigen Schreibvorgang aufgetreten sein oder der GAU tritt ein. Das wäre dann der Fall, wenn eine Platte einen Fehler in der Partitionsstruktur enthält (Platte scheinbar leer) und die volle Platte mit diesem leeren Inhalt überschrieben würde.
Ein Raid5 per Chipsatz-Controller oder OS zweigt ebenfalls wie das Raid1 zusätzliche Leistung für die Prüfsummenberechnung ab, daher sollte man darauf ohne richtigen Controller für maximale VM-Leistung oder zu erwartender hoher VM-Last mit zeitkritischen Elementen besser verzichten.

In meinen Augen ist jedes Raid ohne eine USV/BBU für die Daten tödlich und verhindert ebenfalls keinerlei Datenverlust durch den Benutzer (Dateilöschen) oder sogar Virenbefall. Von der Warte sind große Datenträger kein Segen, schließlich müssen die auch irgendwie noch irgendwo gesichert werden. Bei einer Schreibleistung von ~100MB/s (Außenbereiche normaler HDDs momentan max 130MB/s, Innenbereiche mit Einbruch auf die halbe Leistung) dauern volle 1TB im Idealfall also 10485,76sec oder ~3h. Da bei 1TB aber meist nur ~976GB nutzbar sind, dauert es daher nur noch 166min...

Oh, das habe ich noch nicht bedacht. Das schweift jetzt etwas ab vom eigentlichen Thema ab, aber dazu habe ich noch eine Frage:

Für den Geschäftsbereich setzt man natürlich ne USV und nen vernünftigen RAID Controller ein. Aber ich betreibe den Rechner bei mir daheim. Und auch mir ist es schon mehrmals passiert, dass eine Festplatte flöten geht. Deswegen dachte ich gleich an ein RAID System. Nur nach deinen Worten bin ich mir jetzt nicht mehr sicher. Was schlägst du denn für den Privatbereich vor, ohne USV und nur mit Onboard RAID. Daheim ist alles nicht ganz so kritisch. Mir reicht es, wenn meine Daten von vor einer Woche, oder zur Not auch einem Monat wiederherstellbar sind. Und den Server würde ich auch mal über Nacht laufen lassen.

OT:
Meine persönliche Dauerkonfiguration ist in meiner Signatur ersichtlich. Das ich einigen Aufwand betreibe, ist mir bewußt. Aber das Konsolidieren von ehemals 7 Rechnern nur aufgrund irgendwelcher SW-Unverträglichkeiten oder weil es schlichtweg keine Treiber für aktuelle Betriebssysteme mehr gibt, haben einfach zuviel Zeit in Anspruch genommen. Dazu fahre ich regelmäßig ein Truecrypt-verschlüsseltes Backup auf eine externe HDD und lagere diese auch noch ausserhalb. Die Platte war ein bisken teurer als andere mit demselben Platzangebot, dafür habe ich aber (wenn auch nicht parallel) die Anschlußauswahl zwischen eSATA, USB2 und Firewire400.

Da du mit Linux fährst, könntest du darüber auch recht einfach mit OS-Mitteln ein Raid1 zu Backup-Zwecken einrichten. Dazu muß die vorhandene Platte aber schon über "mdraid" eingerichtet sein. Im Backup-Fall würdest du dann mit einen x-beliebigen Datenträger das Raid vervollständigen, Linux spiegelt die Masterplatte selbständig auf diesen und nach erfolgreicher Spiegelung nimmst du diesen einfach wieder aus dem Verbund. Allerdings mußt du dort für eine bootbare Zweitplatte eventuell noch manuell einen Bootrecord anlegen. Genaueres sagen dir die "man-pages" von "mdraid" oder/und Google.

Danke für die Infos. Den Tipp mit dem Soft Raid als Backup werde ich mal versuchen. Mir wäre es zwar lieber, wenn ich keine "händischen" Backups machen müsste, aber naja.

Was hälst du von nem CronJob einmal wöchentlich, welches die Daten von der einen Platte auf die anderen kopiert??? Dann könnte ich die Platte einbauen, und lasse nur den rechner mal über Nacht laufen. Oder ginge das auch mit dmraid und nem Cronjob? Also einmal pro Woche in das Raid rein hängen und wenn alles fertig ist,wieder aushängen.

Ich habe ein wenig recherchiert und folgendes gefunden:

# mdadm /dev/md0 -f /dev/sda1
mdadm: set /dev/sda1 faulty in /dev/md0
# mdadm /dev/md0 -r /dev/sda1
mdadm: hot removed /dev/sda1
# mdadm /dev/md0 -a /dev/sda1
mdadm: hot added /dev/sda1
#

Gefunden auf: http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-ig-s390-multi-de-4/s1-s390info-raid.html

Damit könnte man einen Platte aus einem SoftwareRaid raus nehmen und wieder rein geben. Somit sollte ein Backup über nen Cronjob auch gehen. Wenn ich meine beiden Platten habe, gebe ich Rückmeldung,ob es funktioniert.

Der Vorteil des OS-Raids1 besteht meiner Ansicht nach in der möglichen Zusammenschaltung von eigentlich nicht empfohlenen Extrem-Konfigurationen wie SSD und HDD oder Intern und USB/Firewire als Verbund.

Wenn dein OS Copy-on-Write auf dem Datenträger unterstützt oder sogar gleich das ZFS von OpenSolaris mitbringt, ist auch so das Backup auch ohne Raid kein Problem und läßt sich dann neben dem Scripten auch als Cronjob hinterlegen. Man könnte natürlich auch einen Trigger auf Dateiänderungen bestimmter Dateien einrichten, der bei Veränderung flexibel ein "rsync" anschiebt.

In welchem Zeitraum muß denn das Backup eigentlich wieder einspielbar oder lauffähig sein?

Wie gesagt, es ist privat. Hauptsache die Daten sind nicht zu alt. Und wenn ein cp die Daten "spiegelt", dann brauche ich die andere Platte nur sauber einzuhängen.

PS: Ich will übrigens nur die Datenplatte mit den VM's regelmäßig sichern. Die Systemplatte ist in ner Stunde wieder da und deswegen brauche ich davon keine Sicherung.