Failed import from ESXi 7
-
@BGDev What I'm trying to determine is if there is already an amount of space consumed on your xcp-ng pool's SR that would correlate with the disk in question.
You mentioned a 3TB disk (and above you mentioned the 2TB limit) was this a typo?
-
As I am aware, there is a limit on the size of guest VDI. So VMs can have a max disk size of 2TB. The 3TB HDD is completely empty with 2.7TB free after format. So in whole, the VM has a total of 2.23TB in 3 disks, and is being imported to a 3TB disk/SR with 2.69TB free.
I hope this clarifies this for you.
-
@BGDev Okay, so you have 3 disks that you're importing from VMWare, and the largest is 1.8TB (thick provisioned).
In the logs above there is the error message
Error: already finalized or destroyed. Does this 1.8TB disk already exist on your XCP-ng pool? -
No, when the import completes, all 3 disks are deleted from the SR. The SR is empty.
Edit: the 2 smaller drives import and can be interacted with because they finish much sooner. But when the last one finished, they all disappear and the SR is empty.
-
Here is the sr-list output of the 3TB SR.
uuid ( RO) : b588531a-0ea4-beba-fa6f-94ef1b6c16cf name-label ( RW): HDD_3T name-description ( RW): Old 3TB HDD host ( RO): xcp-ng-main allowed-operations (SRO): VDI.enable_cbt; VDI.list_changed_blocks; unplug; plug; PBD.create; VDI.disable_cbt; update; PBD.destroy; VDI.resize; VDI.clone; VDI.data_destroy; scan; VDI.snapshot; VDI.mirror; VDI.create; VDI.destroy; VDI.set_on_boot current-operations (SRO): VDIs (SRO): PBDs (SRO): d340fec0-3c1c-d808-906e-856674c3da46 virtual-allocation ( RO): 0 physical-utilisation ( RO): 2125824 physical-size ( RO): 2952313094144 type ( RO): ext content-type ( RO): user shared ( RW): false introduced-by ( RO): <not in database> is-tools-sr ( RO): false other-config (MRW): auto-scan: true sm-config (MRO): devserial: scsi-350014ee20ab0a29a blobs ( RO): local-cache-enabled ( RO): false tags (SRW): clustered ( RO): false -
@BGDev As a thought, you can export the 1.8TB drive and manually import it to your environment using Xen Orchestra (rather than attempting to export the VM as a whole)?
Once imported you would simply attach it to the VM.
-
Thank you for the suggestion.
If I am going to manually import the data, I will just remove the 1.8TB virtual disk in ESXi and import the VM. Then take out a 10GB NIC from one of my servers and just transfer the files to a fresh new disk. My issue is that I don't have any drives big enough to hold that drive for the export easily. I have a few options to get the data transferred, but if this is a bug I would like to help get it addressed.
Again, thank you for the help troubleshooting the issue and your suggestions to work around the issue.
-
@BGDev Sorry just had a thought. Is this 1.8TB drive for a fileshare etc?
If so, why not create a new drive on XCP-ng and simply use a copy operation to move the individual files and permissions over?
-
That is my plan if I don't find a XCP-ng based solution. I will just scp the data over to a new drive. I have lost so much time that I am just letting it run as is and figuring out the best path forward. When I have a bit of time I will settle on the best path to take. I am still learning XCP-ng and would like to learn more as well as possibly help iron out a bug if this is one. If this is a bug it is best to leave everything intact as it is so that I can troubleshoot it more.
Thank you for the sugestions.
-
@BGDev I'm not certain you're encountering a bug or a network issue (or something else).
Given that you have a working production workload on ESXi and a Production XCP-ng environment, what I personally would suggest is to replication the data from the old to the new, schedule a final cut over day and perform a final replication.
If this was a database drive or something that help system files then I'd dig further into why its not exporting successfully, but since it seems like its just a file share, replicating the individual files would be the simplest approach.