Univention Bugzilla – Bug 23445
Qemu cache-Strategie per UVMM-UMC-Modul konfigurieren
Last modified: 2012-12-12 21:07:38 CET
+++ This bug was initially created as a clone of Bug #22231 +++ Anlegen/Wiederherstellen/Löschen eines Snapshot dauert sehr lang wenn das Image auf einem NFS Share liegt und die Instanz läuft Ursache ist die Verwendung von "writeback" als Standard-Strategie von libvirt, was dazu führt, das jeder Schreibzugriff per O_DSYNC stattfindet und jede Operation an kritischen Datenstrukturen vom Qcow2-Format zusätzlich per fdatasync() einen synchronen Zugriff auf die Platte erzwingt. Bei NFS bedeutet das jedes Mal ein Round-Trip zum NFS-Server. Siehe auch Bug #23091. "writethrough" muß wegen der Datensicherheit der Standard bleiben, jedoch sollte der Benutzer eine Möglichkeit haben, die Einstellung per UVMM-UMC Modul in den erweiterten Festplatteneinstellungen selber anzupassen. Diese Einstellung sollte auch per Profil vorbelegt werden können.
(In reply to comment #0) > "writethrough" muß wegen der Datensicherheit der Standard bleiben, jedoch > sollte der Benutzer eine Möglichkeit haben, die Einstellung per UVMM-UMC Modul > in den erweiterten Festplatteneinstellungen selber anzupassen. > Diese Einstellung sollte auch per Profil vorbelegt werden können. Muss "writethrough" wirklich Standard bleiben?
(In reply to comment #1) > (In reply to comment #0) > > "writethrough" muß wegen der Datensicherheit der Standard bleiben, jedoch > > sollte der Benutzer eine Möglichkeit haben, die Einstellung per UVMM-UMC Modul > > in den erweiterten Festplatteneinstellungen selber anzupassen. > > Diese Einstellung sollte auch per Profil vorbelegt werden können. > > Muss "writethrough" wirklich Standard bleiben? Ich habe mal die Unterschiede aufgeschrieben: <https://hutten.knut.univention.de/mediawiki/index.php/Philipp_memo/Qemu#Cache-Strategien> Allerdings würde ich das gerne auch noch mal mit Zahlen untermauern wollen. Gefühlt würde ich "none" als Default vorschlagen, denn da wird kein "sync" erzwungen, was es langsam macht, aber durch das O_DIRECT ist sichergestellt, daß die Daten auf die Platte geschrieben werden. Solange das Gast-Betriebssystem selber seine Caches korrekt flushed, sollte das sicher sein.
Die Cache-Stargetie kann nun geändert werden, wenn man (nachträglich) im UVMM-UMC-Modul auf dem Geräte-Tabulator ein Block-Gerät öffnet. Beim neu Anlegen erscheit die Auswahl nicht; statt dessen wird das Default aus dem gewählten Profil verwendet bzw. "none". Xen ignoriert diese Einstellung derzeit, weil tapdisk sein eignes Ding macht. svn36681..2 univention-virtual-machine-manager-schema_3.0.4-1.51.201210261527 univention-virtual-machine-manager-daemon_2.0.12-1.400.201210261528 ChangeLog: svn15395 \item The cache strategy for block devices can be configured now. The default was changed to \emph{none} (\ucsBug{23445}).
(In reply to comment #2) > Ich habe mal die Unterschiede aufgeschrieben: > <https://hutten.knut.univention.de/mediawiki/index.php/Philipp_memo/Qemu#Cache-Strategien> > Allerdings würde ich das gerne auch noch mal mit Zahlen untermauern wollen. Zahlen wurden nachgeliefert für eine automatische Installation von UCS-3.0-2 ohne anschließende Updates auf xen5.
0004-Bug-23445-cache-none.patch: für pc-0.1x-VMs wird jetzt cache=none als default verwendet; eine explizite Angabe hat natürlich Vorrang. svn11068, qemu-kvm_1.1.2+dfsg-2.24.201211061919 ChangeLog: ±0 Ggf. ist noch folgendes zu ergänzen: \item The default cache strategie on the host for image files of virtual machines of versions before pc-1.0 has been changed to \emph{none}, which by-passes the host cache completely and not forces a disk sync after each write (\ucsBug{23445}).
Es ist Bug #29249 aufgefallen.
Die Caching Strategie kann konfiguriert werden. Für CD-Laufwerke ist der Standard auch "none" - sollte hier nicht auf writeback gesetzt werden, für Lese-Caching (was sich bei read-only Medien anbietet)? Allerdings scheint wenn überhaupt nur "unsafe" die Snapshots zu beschleunigen - allerdings fehlen harte Zahlen.
Im UVMM UMC-Modul wird auch für XEN-Instanzen die Konfiguration des Cachings angeboten
Derzeit kann die Eigenschaft auch im laufenden Betrieb geändert werden. Soll das?
Es wäre gut, wenn der echte Name in Klammern dahinter steht, also (none, unsafe, usw.). Dann finden die Admins vielleicht auch in weiterführender Dokumentation etwas zu den Werten. Alternativ als Tooltip.
(In reply to comment #7) > Für CD-Laufwerke ist der Standard auch "none" - sollte hier nicht auf writeback > gesetzt werden, für Lese-Caching (was sich bei read-only Medien anbietet)? svn37373: 'none' für disk, 'default' für alles andere. (In reply to comment #8) > Im UVMM UMC-Modul wird auch für XEN-Instanzen die Konfiguration des Cachings > angeboten svn37372: Wird nur noch für kvm angezeigt. (In reply to comment #9) > Derzeit kann die Eigenschaft auch im laufenden Betrieb geändert werden. Soll > das? svn37370: Das Editieren der Einstellungen für laufende VMs wurde jetzt komplett deaktiviert, scheitert aber derzeit an Bug #29269. (In reply to comment #10) > Es wäre gut, wenn der echte Name in Klammern dahinter steht, also (none, > unsafe, usw.). svn37367: Wurde ergänzt. 2.0.20-1.410.201211201403 ChangeLog: ±0
(In reply to comment #11) > svn37373: 'none' für disk, 'default' für alles andere. OK > svn37372: Wird nur noch für kvm angezeigt. OK > svn37370: Das Editieren der Einstellungen für laufende VMs wurde jetzt komplett > deaktiviert, scheitert aber derzeit an Bug #29269. OK > (In reply to comment #10) > > Es wäre gut, wenn der echte Name in Klammern dahinter steht, also (none, > > unsafe, usw.). > svn37367: Wurde ergänzt. OK Ich habe das Changelog noch leicht angepasst.
Bei CDROMs trat noch ein Traceback auf: File "/usr/lib/pymodules/python2.6/univention/management/console/modules/uvmm/domains.py", line 237, in _create_disks drive.driver_cache = disk[ 'driver_cache' ] KeyError: 'driver_cache' Das kann von Jascha bspw. auf xen13 reproduziert werden: - eine VM auswählen - Medium des Optischen Laufwerkes ändern - auf speichern klicken Ursache ist, daß für CDROMs jetzt "default" verwendet wird, was beim wiederauslesen dann aber dazu führt, daß das Atribut nicht angezeigt wird und damit den KeyError auslöst. In dem Fall wird jetzt einfach .get(..., 'default') verwendet. svn37436, 2.0.28-1.419.201211230959 ChangeLog: ±0
Noch ein paar Erkenntnisse von der ML: 1. in einer neueren QEMU-Version (1.2 oder 1.3 habe ich bisher nicht herausfinden können) ist die Standard-Strategy nicht mehr write-through, sondern write-back. 2. 'none' funktioniert nicht mit jedem Dateisystem. Es gibt unterschiedliche Berichte, daß es mit Linux-NFS (nicht) funktioniert. Deswegen ist 'writeback' jetzt default und nicht 'none'. 3. K.Wolf hat die Beschreibung der Strategien mit <1353936109-10877-2-git-send-email-kwolf@redhat.com>> aktualisiert und beschreibt ganz gut die Unterschiede.
(In reply to comment #13) > Bei CDROMs trat noch ein Traceback auf: > File > "/usr/lib/pymodules/python2.6/univention/management/console/modules/uvmm/domains.py", > line 237, in _create_disks > drive.driver_cache = disk[ 'driver_cache' ] > KeyError: 'driver_cache' > > Das kann von Jascha bspw. auf xen13 reproduziert werden: > - eine VM auswählen > - Medium des Optischen Laufwerkes ändern > - auf speichern klicken Tritt nicht mehr auf.
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".