Disk information in configuration not loading after migration and modification -- VM running

[BTesdall71]

Good afternoon,

Over the weekend, I migrated a very large VM from an old Hyper-V host to a new VMWare vSAN 2-node cluster.  The migration took a considerable amount of time, and once it was done, after making a couple of changes to the configuration, I booted the VM and it came up just fine.  Installed VMWare Tools.  So far so good.

After installing VMWare Tools and making a couple of network changes, I took a look at the VM configuration and the second HD on the VM was showing a very peculiar size, something like 2.64148746164 TB (not the exact number, but you get the idea).  I went into this and set the second HDD to be an even 3TB while the machine was running.  The change was done, seemed to take effect within the VM, I was able to expand the disk as expected.

But now when I go into the VM in vCenter and select this VM, at the top of the VM information window, I have a blue bar that says:  Some of the disks of the virtual machine XXXX failed to load. The information present for them in the virtual machine configuration may be incomplete

When I go into the VM configuration, the second HDD shows a capacity of 0 MB, but does point to a VMDK file and the VM is running normally.  The data on the second HDD is available within the VM and also over the network (this drive has a bunch of shared folders).

What can I do to correct this issue, mostly for my own peace of mind?  Would a reboot of the VM fix this, or do I need to do something like shut down the VM, disconnect the second VMDK, and then reconnect it?

Thanks!

[TheBobkin]

@BTesdall71, Not to cause panic, but a vmdk showing as 0B in size can be a bad sign - can you check that all looks healthy via Cluster > Monitor > vSAN > Skyline Health > Retest ?

On a side-note: a vmdk showing as 2.12345678 TB means whatever was used to migrate/deploy it did so with non-1 MiB alignment which is bad for other reasons.

[BTesdall71]

I've run a retest of the vSAN health and everything is green across the board, except for a handful of informational items that are completely and certainly unrelated.

I used the VMWare vCenter Standalone Converter, which I always use for these, and it's the latest version AFAIK.

What you said about the alignment I suppose could be possible.  I've had a few issues migrating VMs from this particular HyperV host to the vSAN.  In 3 cases, including this one, the converter could not properly detect the OS of the VM when it was off.  In all of the other migrations I've done, which are many, I hadn't run into this problem before.  The converter registered the OS as "Other (32-bit)" even though the VM was running Windows Server 2019 64-bit.  This means that the converter didn't know what SCSI controller to give the VM, and also was unable to do reconfigurations after the data copy was done.  In the previous 2 cases, the initial attempts resulted in unbootable VM's.  But I figured out that setting the SCSI controller to the LSI Logic SAS before conversion and then setting the operating system manually in the VM once it was in vSphere got around the problem and the VMs would boot and appear to be working normally.

I'm not sure if that "failure to detect the OS" has something do to with the issues of the 2nd HDD.  How can I remedy this situation?  Could I try cloning the VM?  Or just disconnect the VMDK that has an issue and then reattach it?

[BTesdall71]

I looked a bit more at the 2nd HDD and its storage policy is set for "Datastore Default" even though the VMDKs are on a vSAN Datastore.  What would happen if I reset the policy to "vSAN Default Storage Policy"?