Linguiring VDI Export task after backup fails
-
I have failing backups that leave behind an Export task of a VDI.
I noticed that there are multiple VHD snapshots remaining that are assigned to the Control Domain.
Can I just delete these? The backup error is "HTTP connection has timed out". I have since added more vCPUs and memory to the Xen Orchestra and will see if this resolves the problem, but I want to know if I can delete these remaining VDI snapshots first.
EDIT: I forgot to add that the VM is Windows and has multiple VHDs attached. None of the other VHDs have this issue. Just the one VHD.
-
Restart xo-server will kill those backup jobs. The task will disappear after 24h or immediately if you restart the XAPI toolstack
-
@olivierlambert It only just occurred to me that the "HTTP connection has timed out" could be Xen Orchestra timed out communicating with XCP-ng. If that is the case then more vCPUs and memory on the Xen Orchestra VM wouldn't solve this problem would it...? I suppose I will see.
-
It's hard to tell, it can be a network issue, XCP-ng timing out, not enough Dom0 memory and so on…
-
@olivierlambert oh, yes! That makes more sense. Xen Orchestra is running as a VM on the same host, so it seems unlikely to be a networking issue.
-
@olivierlambert The issue turned out to be a problem with the VHD files. The VM is a Windows VM converted from a physical server with disk2vhd. There were 3 disks in total that I had converted.
To resolve the issue, I created a bootable WinPE.vhd (with storage and DISM tools added) as well as another VHD as a temporary holder for .WIM files. I captured the contents of each VHD from the disk2vhd conversion into .WIM files on the temporary VHD. Then I created new .VHD files and applied the .WIM files to the new VHDs.
After this process, the backups are working.EDIT (Important): I had to re-create the EFI boot partition and use bcdboot.exe to setup the Windows boot. I also made sure that the new .VHDs had the same drive letters assigned as the originals while in WinPE and have the new .VHDs assigned to the VM in the same order that the originals were.
-
A badly formated VHD can indeed trigger this, nice catch!
