Hi all,

I have noticed that when I export a VM from XO as a XVA file (no compression), the file is sometimes not usable. It looks approximately the right size.

For example, exporting the same stopped VM five times in a row gives me XVA files of five different sizes:

  9975006379 Oct  3 13:14 '20251003T121256Z - XXX.xva'
 13504108339 Oct  3 13:27 '20251003T122555Z - XXX.xva'
 11840604190 Oct  3 13:32 '20251003T123120Z - XXX.xva'
  9924612837 Oct  3 13:34 '20251003T123339Z - XXX.xva'
 10033681176 Oct  3 13:35 '20251003T123454Z - XXX.xva'

And as XVAs are basically TAR files, I can verify that some of these appear to be truncated:

$ tar tf '20251003T122555Z - XXX.xva' > /dev/null
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

Of the above five copies of the same VM, only the first is valid according to tar (strangely, some of the invalid files are longer than the valid one, even though tar thinks they're incomplete files!).

My workflow for downloading these files from XO is

1. Ensure the VM is shut down
2. Click the 'Export' button on the VM page in XO
3. Leave the defaults (xva format, no compression) and click OK
4. Copy the download URL
5. Paste the URL after wget -T0 (I add -T0 because I've seen these downloads time out XO/xapi doesn't respond for a while whilst constructing the file)

Has anyone else experienced this? Any ideas?

Thanks.

@olivierlambert Aha, thanks

I have some VM templates with large (tens of GB) disks attached.

Creating a VM from these templates used to be near-instant as XO would do a fast (copy-on-write) clone of the template disks.

Recently it seems XO has started doing a full copy of the template's disks when creating a VM. VM creation from these templates now takes several minutes and I see long-running VM.copy and Async.VDI.copy tasks in the task list whilst this is happening.

Was there a deliberate change to making VM creation do a full copy rather than a fast clone?

Thanks.