moving to a new vCenter vm

[joebrug]

My current vcenter is having issues and I needed to create a new one. I understand that moving VMs to a new vcenter will cause Veeam backups to start "fresh" due to ID changes. It looks like 12.3 of B&R includes a Migrator tool that is supposed to alleviate this issue and allow the vm's to continue with "incremental" backups. Looking at the documentation mentions some PowerShell commands, but while it explains the commands, it doesn't exactly explain steps to run them. Does anyone have experience with these commands/tool?

My assumption is the first command "Set-VBRVmBiosUuid" needs to be run on Veeam server before moving any VMs to the new VCenter machine. The other commands, it's unclear to me when to run.

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

[david.domask]

Hi joebrug,

Correct, run the command before draining the previous vCenter of VMs, then proceed through the commands in order.

Please remember to take a Configuration Backup prior to starting the process so you can roll-back if required -- this is to preserve the state of the configuration database so we can generate the migration file again if required or to recover to the previous state temporarily.

[joebrug]

hi David,
thanks for the response! Just double checking to make sure my order of operations is correct. Assuming current vcenter server is called "vcenterold" and new is "vcenternew"...

On the Veeam server, launch PowerShell and:

1. Take configuration backup of Veeam
2. Set-VBRVmBiosUuid -VCenterName "vcenterold" (Collects MORef IDs from orig server.)
3. Use vmotion to move all of the VMs from "vcenterold" to "vcenternew" (including both vcenter vm's)
4. Set-VBRVCenterName -OldVCenterName "vcenterold" (Modifies VMware vCenter name to vcenterold_old.)
5. Generate-VBRViMigrationSpecificationFile -ExportPath C:\Folder -NewVCenterName vcenternew -OldVCenterName vcenterold_old (Generates a migration task file)
6. Start-VBRViVMMigration -File C:\Folder\vcenter70_old_to_vcenter70_migration_task (start the MORef IDs update.)

Does anything need to be done in Veeam after this? do you have to add the new vcenter to the Veeam Inventory (it has a dif IP now) or is that part of this process? Anything else I may be forgetting?

Thanks again

[joebrug]

Bumping this. Also, curious if you think Quick Migrate would accomplish the same thing instead of trying to use these commands?

[david.domask]

Hi joebrug,

Apologies for delayed response, I was out of office last week.

Process looks good, but you will need to add the new vCenter some time before step 5, as step 5 will "inventory" both vCenters and create a list matching the inventory of the vCenters and mapping the old VMs + morefs to new VMs + morefs.

An example of the Migration Specification File:

Code: Select all

// hosts names
old-vcenter.local_old 	-> new-vcenter.local
	// solid
vm-141368 	 dd-tinyvm3_VRORESTORE 	 7fd17fb4-492d-47a7-8f79-41f93700c38b 	->  vm-141368 	 dd-tinyvm3_VRORESTORE
vm-136760 	 dd-tinyvm 	 a8551755-ea3c-4815-beb8-482c6bf5cccc 	->  vm-142199 	 dd-tinyvm
vm-136762 	 dd-tinyvm3 	 293fb27a-8f83-448e-b50c-f351a7bdc561 	->  vm-136762 	 dd-tinyvm3
vm-139833 	 dd-vm-bulk-delete 	 77fb7179-760d-4b7a-9d57-f471c0ad174b 	->  vm-139833 	 dd-vm-bulk-delete
vm-136761 	 dd-tinyvm2 	 7e2232ba-50ca-4532-b968-f9242277af48 	->  vm-142200 	 dd-tinyvm2
	// probable
	// old duplicates
	// already migrated
	// not found
vm-141365 	 dd-tinyvm2_VRORESTORE 	 af975ffd-8a58-4716-ac3a-1c411bd96946 	->
vm-141364 	 dd-tinyvm_VRORESTORE 	 6fb45115-16cf-4ac4-8e45-4bf3839401b8 	->

You can see how it does the mappings here for my few test VMs i worked with, and we're just updating the Veeam Configuration Database to ensure that we preserve the mapping after migration.

Quick Migrate can work in conjunction with the new cmdlets also, so it's dealer's choice how to do the actual VM migration.

[joebrug]

Welcome back, David Hope you enjoyed your week

I do have a case open about this 07574242 .. support is struggling to find folks who have any experience with this tool

Last week I did test the Quick Migrate option. When the VM migrated, it didn't have any Network chosen under settings, so there was downtime. I'm not sure if this is because I didn't choose to delete the source VM. Nevertheless, it seems like the "tool" would be the right way to accomplish this. A little worried about shooting self in foot

[joebrug]

Well, followed the steps in order listed.. moved all the VMs to new vcenter. Added "vcenter.mydomain.com" to VeeamBR inventory. Then ran the rest of the commands. Jobs are failing with "vc.mydomain.com_old" is not available (this is for VM "PID"). Virtual Machine PID is unavailable. Not sure what my next steps should be to right this ship. Or just bite the bullet and change all the jobs to reflect the VM from the "new" vcenter.

The migration file is below.

Code: Select all

	// hosts names
vc.mydomain.com_old 	-> vcenter.mydomain.com
	// solid
vm-502461 	 RDS4 	 287b6236-e354-4421-a032-27484077775a 	->  vm-1093 	 RDS4
vm-482474 	 RDS2 	 52c2c894-e000-429a-aa2a-1a7438da3345 	->  vm-1100 	 RDS2
vm-486614 	 RDS3 	 cc275a36-d62e-49fa-8fff-75ea31530deb 	->  vm-1101 	 RDS3
vm-473317 	 RDS1 	 dea99a0e-1565-46ad-a325-273223fecba2 	->  vm-1099 	 RDS1
	// probable
	// old duplicates
	// already migrated
vm-485453 	 DEV19 	 00507b68-c671-495c-bf85-8a13a650b98c 	->
vm-471382 	 DC2 	 0930ef26-8f56-439c-ae93-77e27113872f 	->
vm-523639 	 PID 	 1153713a-6628-4941-990b-a03cdc8870fc 	->
vm-471138 	 DC1 	 1469eb9e-3108-4a23-8850-713009384cc4 	->
vm-404591 	 CMP 	 166cd7b2-81e4-4881-a56e-c36297dde5c1 	->
vm-645125 	 IMAGING 	 1c79fbba-5046-4c86-a2ef-e56f7a92d232 	->
vm-396188 	 App2 	 1e0eefd8-dfe0-4aa3-acb9-b6ce06d21092 	->
vm-645297 	 PID 	 2316a522-93a5-44a2-a935-3fe0fb3852fb 	->
vm-526911 	 IMAGING 	 27e08b98-e12c-480f-871d-9ce8dd890c01 	->
vm-522698 	 Print 	 2c1b673f-ca2a-477a-9096-f6b91ffa3788 	->
vm-527667 	 Biscom 	 2d43bcb0-67f9-4019-ac1f-302a287c8267 	->
vm-361327 	 FileServer2 	 31394128-3a4b-45f9-9eca-7af0a655f961 	->
vm-411658 	 IT7 	 35f45c46-5940-450a-be04-30f3f99fd73f 	->
vm-603083 	 vCenter Server-Restore 	 499ebeb2-8612-4dca-b13b-13f6792f4890 	->
vm-489283 	 NetwrixAuditor 	 5e5fcb68-675c-45b5-8add-18af71d26893 	->
vm-72 	 Apps 	 69187264-76f8-4d7b-ab79-8dc43d50fb92 	->
vm-645114 	 VMware vCenter Server 	 7350b46a-c4c6-400d-9ea7-fd92366f5fbe 	->
vm-555452 	 auvik-bplawhq 	 78ff10b0-8805-45c6-ac2c-13adb049f786 	->
vm-517744 	 PDQ 	 892c329f-a706-40b3-b9f0-b184d0ee1b32 	->
vm-485325 	 LIVE19 	 94326244-9162-4e14-8a12-d578f1f81cb6 	->
vm-525919 	 BK 	 b32e9b51-5eb9-4cd1-8e99-f480bda120d1 	->
vm-584917 	 RDS5 	 b50dc2c0-2a84-4589-9f39-d412324d6fde 	->
vm-478669 	 Veeam Backup Proxy 	 c09b4945-7ef6-429e-9900-c74f116df155 	->
vm-584309 	 Gwava Retain 	 c4fa47ac-3547-471b-b558-b22fe4aae175 	->
vm-406275 	 WEBAPPS 	 d0b90db5-ae8f-407a-acb8-bec5887868d3 	->
vm-404313 	 DEV 	 decc7e58-64fb-4ded-b56b-9d8744cbb085 	->
vm-584894 	 Thunderstone 	 df35b20f-0711-423f-9c07-74301bb289f4 	->
vm-404252 	 LIVE 	 e36011e4-b6c0-47c6-a454-1d9fbdf3db51 	->
vm-44 	 SVN 	 f7b2e621-dde9-4728-82df-279a9383d84b 	->
vm-565375 	 FSLogix 	 fd9d7e81-81e8-487e-9141-d590b29b258e 	->
vm-304224 	 FileServer1 	 ff7f26c6-5508-4955-a51a-f0c633088ef7 	->
	// not found
vm-469445 	 Win10 - Reference 	 1c5b3db6-21ae-4e44-bef6-3f00a13b928e 	->
vm-560080 	 vCenter Server 	 1cc46a8b-45fc-4779-9799-ce0134e10247 	->
vm-548736 	 GMS2 	 2410b14f-926f-4fa7-b68c-da90bbc8a3f5 	->
vm-482997 	 Gwasbpo 	 2a728d3b-b235-4861-b7ee-5e342cfe21e7 	->
vm-561152 	 Thunderstone 	 306f7a5b-5e35-4539-8ec2-41f20f0a19bb 	->
vm-584820 	 Thunderstone-1695138 	 3f26f107-2b42-4816-aeb8-26bb3011ee28 	->
vm-560083 	 vCenter Server 	 44dc568b-7612-47c4-93ea-285b09781be1 	->
vm-466130 	 VCSA67 	 4e1a002d-4e30-4816-962c-5bc0938a633a 	->
vm-469866 	 PID 	 5f2e580d-3bfe-4dd1-8cb8-ba1d242902d8 	->
vm-590082 	 vCLS-fecc4845-f660-4338-a054-6156ec75bb2e 	 61f559b0-2d86-445b-b5ba-a0b1f8d7486f 	->
vm-212129 	 Evault vSphereAgent 	 65e6647a-df80-4323-a311-b30212438458 	->
vm-551806 	 NetGovern-Archive-6.4.0.1188-EX 	 67adb944-dac6-446b-b975-46b422748dbd 	->
vm-47 	 Biscom 	 7750b586-8e09-456b-94f1-cfc49cba45e6 	->
vm-645111 	 VMware vCenter Server 	 7b323b5b-28f4-44b0-ab30-80155cfa99da 	->
vm-493800 	 ZENworks2020_Appliance-x86_64-20191004-3137 	 7c972d6f-6a93-4d25-8488-a04b496bd6b1 	->
vm-388982 	 Win7 - no client 	 83f63c04-5eee-44f6-8d2d-2e6c15755bd6 	->
vm-551233 	 NetGovern-Index-6.4.0.1188 	 9f8a5a64-ae57-42c1-b44b-1fa67f8c3bfb 	->
vm-475561 	 GwDomain 	 a0f9d90b-76fc-4403-99f5-63db83f97405 	->
vm-551227 	 NetGovern-Archive-6.4.0.1188-GW 	 ad7dde1a-31dd-4b26-b4e0-ab501b5f1220 	->
vm-420495 	 Win7-32bit 	 b3a9410d-6aee-4e79-a014-f8ff5179ba12 	->
vm-475287 	 iPrintAppliance.x86_64-4.0.0.66 	 b7a11b14-3707-4e14-bfdf-0455db1240ad 	->
vm-470968 	 GMS 	 baac366e-59c1-4ca2-8852-ddfbc992ee72 	->
vm-522854 	 Windows 10-Test 	 bd6385e3-0e1d-46d3-928d-97bda4c4fc69 	->
vm-366688 	 Nexic 	 c2e1e9de-7a2f-41e1-a6df-ea522bee25dc 	->
vm-590083 	 vCLS-8bea836b-b6ad-4d07-acc9-b82105db2c54 	 d320dc4a-7303-4317-b5ca-ee04f25aa744 	->
vm-590081 	 vCLS-1c72a769-fdaf-4667-bf19-3b51151c8ab7 	 d8563ac1-cad8-4533-9301-9374d1415680 	->
vm-509558 	 Observium 	 dc3cd44c-648e-4dbb-9712-ba7926d610ca 	->
vm-152955 	 Gwava Retain 	 e3ec531e-b3b0-4233-a5cd-53addee5045f 	->
vm-478493 	 MainPO 	 e9cbee2d-aa0c-42ef-a82c-65fa5e510b13 	->
vm-586345 	 Windows-10-Autopilot 	 f3f2008f-453c-4d72-98da-4f4d7668e230 	->
vm-584798 	 Thunderstone-1695138-BraytonPurcell-1699363 	 f60b6ab2-a8a3-4935-aef6-becdafe8624b 	->
vm-527162 	 GMS-New 	 ffb15156-f404-4c07-aabc-a63677332ce0 	->

[david.domask]

Hi joebrug,

Sorry to hear about the challenges -- I would first start with rolling back the configuration database with a configuration restore, using a configuration backup from before the change.

Then please open a Support case and let Support take a look at what's going on and review the steps that were taken.

The "already migrated" section shows that a lot of the machines detected were not mapped under the new vCenter, unclear as to why, but a Support case is probably best bet.

>Or just bite the bullet and change all the jobs to reflect the VM from the "new" vcenter.

This is an option as well as I understand time is a factor here, but to understand why the migration cmdlets did not work, it's best to let Support review. Please share your case number here once created if you go this route.

[joebrug]

hi David, I had already posted it (I believe I posted twice since your response yesterday, so you might've missed the first one) Case: 07574242

This tool seems very foreign to support I've escalated the issue, etc.

I'm not sure why the RDS VMs seem to have "worked" but the rest didn't. I do have configuration backups. I have paused all jobs for now but obviously dont want to keep that for long

[david.domask]

Ah, apologies, I indeed forgot you added it previously. Coffee hasn't gotten through me yet I guess this morning

I will review the case with Support.

[joebrug]

No worries. In case you're following along.. case got escalated (again?). Engineer sent me an email with instructions attached for the Veeam.Backup.VmMigrator.exe , which I believe was replaced by the powershell commands (?). Sigh

[joebrug]

Keeping topic updated..

a little progress, have sent in backup files and logs. This time the VMs appeared in //solid , but warned when running the migration:

Code: Select all

Parsing VMs mapping
Warning: Already have BObject for this target VM (name: DEV19, reference: vm-1092). Line ignored: vm-485453      DEV19  00507b68-c671-495c-bf85-8a13a650b98c    ->  vm-1092      DEV19
Warning: Already have BObject for this target VM (name: DC2, reference: vm-1086). Line ignored: vm-471382        DC2    0930ef26-8f56-439c-ae93-77e27113872f    ->  vm-1086      DC2
Warning: Already have BObject for this target VM (name: DC1, reference: vm-1089). Line ignored: vm-471138        DC1    1469eb9e-3108-4a23-8850-713009384cc4    ->  vm-1089      DC1

Viewing a backup job > Virtual Machines, size shows 0 after "recalculate" is pressed.

[Zew]

I've tested building a vCenter from scratch.
Generally just, build new vCenter, add hosts.
Go through the object wizard in Veeam to ensure certificate is trusted and vCenter can be scanned.
Use SQLCMD to edit the VM Id's.
Done. This is the unsupported method I've done in my home lab many times, and somehow event eh chains are unaffected and keep working.
You can look it up my blog for detailed instructions. Best of luck on your endevours.

[joebrug]

Thank you for the response.
Believe I found your blog and looked at the instructions. Looks simple enough (although we use Postgres, so I'd have to figure that out).
I'm not sure why support is having such a hard time with this if it is that simple (and now supported with the powershell cmds). I think we're now escalated to tier 3 support.
Frustrating, but might have to take this in my own hands now as we haven't' had a backup since last week due to this. or just bite the bullet and create new chains.

[RubinCompServ]

@joebrug

As we start moving towards VCF, we're going to face the same issues you are. Have you gotten a resolution for this issue?

[joebrug]

They at least wrote better documentation on the utility. I believe my situation is too far gone to follow these steps to test it

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

[Zew]

Oh nice didn't know they made a PowerShell cmdlet for this now. Thanks for the share, will have to test and update my blog. Much thanks for the update.