Voller Enthusiasmus nach der Migration unserer Xen-Server-Umgebung auf Version 5.5, habe ich gestern angefangen, unsere virtualisierten Maschinen zu sichern.

Das Script, das ich dazu erstellt hatte, arbeitet auch fehlerfrei.

Bis ich auf einmal auf folgenden Fehler lief:

Error code: SR_BACKEND_FAILURE_44
Error parameters: , There is insufficient space,

Eigentlich unerklärlich, eigentlich nutzen die virtuellen Kisten gerade einmal ca. 360GB der verfügbaren 500GB, es sollte also auch für größere Installationen genug Backup-Reserve auf dem Storage vorhanden sein.

Ein Blick auf die Storage-Info im Xen-Center wies dann aber aus:

499,2 GB used of 500 GB total (362,6 GB allocated)

Nicht gelöschte Snapshots konnten es nicht sein, “xe vdi-list is-a-snapshot=true” lieferte kein Ergebnis.

Eine komplette VDI-Liste brachte dann aber zum Vorschein: Jedes Backup hinterlässt zwei neue Disk-Images, auch wenn die gesicherte Instanz schon gelöscht ist. Eine enthält als Beschreibung “Base Copy” und ist Read-Only, die zweite enthält weder ein Label noch eine Beschreibung und ist ebenso Read-Only. Beide Images sind genauso groß wie das Original.

Eine Internet-Recherche ergab: Das Problem ist das “alte” Raw-Format der Platten der VMs, die vor der Migration auf den aktuellen Xen-Server angelegt wurden.

In der von Carl Fischer geposteten Erklärung unter http://bugtracker.vmd.citrix.com/browse/XSB-57 heißt es:

When you create a snapshot the original VDI (”A”) is marked as read-only, a new VDI (”B”) is created to contain the copy-on-write blocks, and third VDI (”C”) is created for the snapshot.

In the non-upgrade case the volume associated with VDI A is then resized down to its actual size on disk, ie if VDI A was 40GB but only contained 20GB of data it’s volume would be resized to 20GB. XS 5.5 does not support thin provisioning on LVM-based SRs so the volume for VDI B will be 40GB even though it only contains the writes that have occurred since the snapshot. VDI C is also a 40GB volume, but it is automatically resized down to it’s actual size on disk (8MB) since snapshots are generally read-only.

In your case because the VDI being snapshotted was upgraded from 5.0 there is an additional implication on the amount of space required in the SR. The parent VDI (A), because it was upgraded, remains of type ‘RAW’ and RAW volumes do not provide a method to determine if a block is actual data or empty. Therefore VDI A’s volume is not resized down to its actual disk space usage when the snapshot occurs.

So in the upgrade case the amount of disk space required in the SR to take a snapshot is the original VDI size x 2. A bit of additional space is required in VDI B for the VHD journaling as well so it’s actually x 2 + ~100MB for a 40GB VDI.

In the non-upgrade case a snapshot requires the size of the original VDI (for VDI B) + the journaling overhead + the amount of data actually present in the VDI prior to the snapshot (for VDI A).

[...] this is specific to upgraded VDIs in LVM SRs. VDIs created after upgrading to 5.5 will be different as described above. NFS SRs, which use file-based VHDs, will not have the provisioning constraints described above that are specific to volume-based VHDs.

D.h., ich brauche in jedem Fall ein Vielfaches der Plattenkapazitäten der virtuellen Maschinen, wenn ich meine Disk-Images noch nicht im VHD-Format habe.

Eine Möglichkeit, die vorhandenen Maschinen von RAW nach VHD zu konvertieren gibt es noch nicht, aber:

We are working on documenting a procedure to ‘convert’ volumes from RAW to VHD but do not have anything available yet.

Super. Also abwarten und Tee trinken…