Univention Bugzilla – Bug 18765
OpenDVDI Instanzen clonen - Copy on write
Last modified: 2019-09-23 09:06:39 CEST
Damit nicht für jeden virtuellen Desktop eine eigene Kopie erstellt wird, sollte geprüft werden, ob Copy on write hier hilft. +++ This bug was initially created as a clone of Bug #18618 +++ Nach der Verteilung der OpenDVDI Templates müssen diese auf den Nodes einfach dupliziert werden.
Testweise habe ich gerade erfolgreich ein Windows unter Xen-3.4.3 geclont: qemu-img-xen create -b "/var/lib/univention-dvs-templates/WinXP-SP3 - (1)/8.img" -f qcow2 /var/lib/libvirt/images/wintest.qcow2 8G disk = ['tap:qcow2:/var/lib/libvirt/images/wintest.qcow2,hda,w',] Interessant an dieser Konstellation ist, daß als Master-Image eine RAW-Datei dienst und für den CoW-Funktionalität das qcow2-Format genutzt werden kann. qcow2 ist das Hausformat von qemu und damit auch von qemu-xen/kvm. Es ist von Haus aus "sparse" und unterstützt auch Snapshots.
Created attachment 2768 [details] Implement CoW using qcow2 image files Anpassungen an UVMM und univention-dvs-node Aktivieren mit ucr set dvs/desktop/cow=qcow2 Getestet auf xen[14] unter xen-3.4.3 Support für kvm ist vorgesehen, aber ungetestet. Zeit für Kopieren entfällt, Benchmark zur Laufzeit steht noch aus: Neben IO-Rate im Gast sollte auch Last auf dem Host betrachtet werden.
Created attachment 2769 [details] Lvm-Benchmark script Unterschiedliche Schreibgeschwindigkeit beim Schreiben auf 1. das real-Device ohne Snapshot: BASE 2. das origin-Device des Snapshots: BASE/4 3. das snapshot-Device des Snapshots: BASE/2
Benchmark mit "time u-d-desktop-create -v -v -v --template WinXP-SP3 ..." Copy SysPrep Total qcow2 0s 300s 5m15s 0s 300s 5m10s 0s 310s 5m24s 0s 290s 5m9s 0s 290s 5m5s 0s 290s 5m13s ohne 198s 320s 8m56s 207s 310s 8m48s 201s 310s 8m56s dm BROKEN Das Template ist eine 8 GiB sparse-Datei, in der 6.2 GiB belegt sind.
Laut <https://www.redhat.com/archives/libvir-list/2010-October/msg00946.html> kann es sinnvoll sein, Preallocation beim Aufruf von qemu-img einzuschalten: qemu-img create -f qcow2 -o preallocation=metadata /dev/null 1M Das wäre noch zu evaluieren.
(In reply to comment #5) > Laut <https://www.redhat.com/archives/libvir-list/2010-October/msg00946.html> > kann es sinnvoll sein, Preallocation beim Aufruf von qemu-img einzuschalten: > qemu-img create -f qcow2 -o preallocation=metadata /dev/null 1M > Das wäre noch zu evaluieren. Backing file and preallocation cannot be used at the same time Umgesetzt in svn20602, univention-dvs-node_1.0.31-2