Failed import from ESXi 7

BGDev

Hello Dustin,

Thank you for helping troubleshoot the issue.

If you mean how much of the disk is used, 1,6TB of the 1.8TB are used. 226 GB are free on the virtual disk. The disk is thick provisioned on ESXi if that makes a difference. The 3TB HDD is ext and thin. The 400GB drive is also thick provisioned and imports fine, so I don't think that is an issue.

DustinB

@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?

BGDev

@DustinB

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.

DustinB

@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?

BGDev

@DustinB

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.

BGDev

@BGDev

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

DustinB

@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.

BGDev

@DustinB

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.

DustinB

@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?

BGDev

@DustinB

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.

DustinB

@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.