Bad deployment and storage size estimation in vCenter migration wizard

When migrating vCenter from Windows to Photon appliance, wizard estimates deployment (vCPU and memory) and storage size – based on data of migration assistant, running on source vCenter. It happens quite often, storage size is much higher than used in Windows vCenter. When do researching, free up disk space is a suggested task. Most often this does not work properly.

Last vCenter I had to migrate to 6.7 managed about 1000 VMs. According to my experience I expected a medium deployment and large storage size. But wizard showed X-Large deployment size (up to 35k VMs!) and storage size (2TB in size!) – and no possibility to change. Current DB (external SQL Server) sized about 50GB. So X-Large was just not acceptable.

After some analysis, it came up, one table in database consumed more than 33GB of 50GB DB size. This table was VPX_TEXT_ARRAY. It had more than 8 million rows. According to KB 2005333 it is safe to delete some rows. As outlined in KB, you can run SQL statement:

DELETE FROM VPX_TEXT_ARRAY
WHERE NOT EXISTS(SELECT 1 FROM VPX_ENTITY WHERE ID=VPX_TEXT_ARRAY.MO_ID)

in vCenter DB. Of course, vCenter services has to be shut down! So read KB carefully. In my case, delete all but about 5k rows took nearly half an hour. Furthermore database log file increased size to about the double of the consumed size of the table. So take care, log file has enough space to grow.  I did not try, but in this blog post, necessary rows are copied to a temporary table, original gets truncated and rows gets moved back. For my understanding this should be done much quicker. After deletion I shrank DB and log files.

When done, I was able to select deployment size between small and X-Large; storage size between default (smallest) and X-Large in migration wizard.

Hint

If you want to know details about deployment and storage size of VCSA, you can run CD-ROM/Disk:\vcsa-cli-installer\win32\vcsa-deploy --supported-deployment-sizes. You get a table of all combinations of sizes and deployed vCPUs, memory and storage. Additionally you see for hot much hosts and VMs this is recommended.