Nach der Verteilung der OpenDVDI Templates müssen diese auf den Nodes einfach dupliziert werden.
Da die Images normalerweise mehrere GiB groß sind, dauert das Kopieren entsprechend lange. Um das zu verbessern gibt es mehrere Möglichkeiten: 1. rsync --compress hilft nicht, weil bei n Servern, auf dass das Image kopiert werden soll, daß Image n-mal komprimiert wird und der Server, von dem das Image heruntergeladen wird, dadurch wegen sehr hoher CPU-Last unbenutzbar wird. 2. rsnyc --sparse wird derzeit verwendet, aber während der Installation werden typischerweise sehr viele temporäre Dateien in der VM angelegt. Diese können zwar einfach gelöscht werden, jedoch sind diese Daten weiterhin in der Image-Datei vorhanden und werden unnützerweise übertragen. Diese ungenutzten Blöcke sollten nach Möglichkeit mit Nullen überschrieben werden bzw. bei Sparse-Files als sparse gekennzeichnet werden. Für ext(2,3) und NTFS gibt es entsprechende Programme: http://man.linux-ntfs.org/ntfsclone.8.html http://web.cecs.pdx.edu/~cklin/wipe2fs/ http://bleachbit.sourceforge.net/ http://packages.debian.org/lenny/perforate ? qemu-img convert -f raw "$in" -O raw "$out" http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Anhang/_qemu-img Interessant ist hier auch das neues Feature von ext4, daß Super-Blöcke erst später bei Benutzung initialisiert. 3. Auch vor einer einmaligen Komprimierung sollten ungenutzte Blöcke möglichst vorher genullt werden. 4. Verteilen per udpcast <http://udpcast.linux.lu/>, da wohl auch von CloneZilla <http://clonezilla.org/> genutzt wird. Das ist insbesondere interessant, wenn ein Image gleichzeitig an mehrere Server verteilt werden soll, da das Netzwerk so nur einmal (und nicht n-mal bei n Servern) belastet wird. 5. Ist allerdings ein Target-Server nicht verfügbar, müssen alle fehlenden Images bei Wiederanlauf nachgefordert werden. Bei Ausfall mehrerer Server kann das ggf. sehr hohe IO-Last erzeugen. Für diesen Fall wäre ein Torrent-ähnliches Verfahren ggf. sinnvoll, bei dem sich alle Server an der Aktualisierung der wiederanlaufenden Server beteiligen (können).
Alles weitere über Bug #18765.
Bastian hatte schonmal angefangen für diesen Einsatzzweck Multicast und Bittorrent gegenüberzustellen: https://billy.knut.univention.de/uniwiki/index.php/Verteilen_von_Images Bei der Verteilung der Templates könnte auch die Load auf dem Quellhost ein Aspekt sein. Rico hatte dazu auf den sendfile-Systemcall hingewiesen, ggf. wäre das in Kombination mit Apache eine Option. Das wäre dann ähnlich zu einem lokalen apt-Repository, nur dass man dann zusätzlich Authentifikation&Autorisierung zu regeln hätte.
(In reply to comment #3) > Bei der Verteilung der Templates könnte auch die Load auf dem Quellhost ein > Aspekt sein. Rico hatte dazu auf den sendfile-Systemcall hingewiesen, sendfile() reduziert nur die CPU-Last beim Sender, die Netz- und Festplattenlast bleibt dadurch weiterhin sehr hoch, wenn alle Server ihre Kopie jeweils von einem einzigen Quellserver ziehen. Da sind Torrents eine interessante Möglichkeit, die Last bei Nachzüglern auf mehrere Rechner zu verteilen. Aufgrund meines jahrelangen Interesses an verteilten Dateisystemen will ich an dieser Stelle auch noch ein interessantes Projekt erwähnen: Für KVM gibt es eine Erweiterung, die das DFS Ceph für den Zugriff auf Block-Devices nutzt: http://ceph.newdream.net/wiki/Kvm-rbd
QA: Nach den Kommentaren zur urteilen scheint Torrent die Lösung mit dem höchsten Potential zu sein. Milestone ist angepasst, und Bug als enhancement für den Fall wieder offen, dass sich hierfür der Bedarf ergibt.
OpenDVDI war der Arbeitstitel für die prototypische Implementierung und wird nicht mehr weiter entwickelt. Für Desktopvirtualisierung mit UCS existiert mittlerweile das Produkt UCS DVS. Sollte der hier beschriebene Bug für UCS DVS relevant sein, so kann dieser Bug nach UCS DVS geklont werden.