moving from sd card to internal SSD

[scale21]

I am working to move from an SD Card install of esxi to Internal storage on a few servers. 

The systems in question are still 6.7 but will get upgraded to 7 after this boot drive swap. 

I know you have to have the same build number before restoring or your host configuration.

Do you sitll need to have the same UUID as well as is this something you can set on a host?

 

My generic process is as follows. 

 

1. backup host config

2. reinstall esxi on host internal drives

3. update and patch to the same build number as the previous version. 

4. restore from backup file

5 re-attach to vcenter. 

 

I guess im reading some older articles saying you need to match both the build number and UUID on the host. Im not sure if this is still required or not. 

Is it hard to force the host to match the old uuid somehow. I know the restore command has a switch to ignore the uuid but im not sure if that will cause problems. The hosts are connected to a vDS but im not sure thats dependent on the UUID.  The hosts in question use Veeam as well but i dont see that causing an issue with different UUIDs as Veeam talks to VCenter and not directly to hosts. 

The goal is to move off SD to internal storage...

 

[Jangari]

You can restore without --force option if you do for the same hardware. The "UUID" in context of ESXi config backup/restore means BIOS UUID (obtain from esxcfg-info -u, smbiosDump), not ESXi's UUID (obtain from esxcli system uuid get, /etc/vmware/esx.conf).

 

How to back up and restore the ESXi host configuration (2042141)
https://kb.vmware.com/s/article/2042141

> Note: When restoring configuration data, the build number of the host must
> match the build number of the host on backup file and UUID (can be obtained
> using the command "esxcfg-info -u") of the host should match the UUID of
> the host on backup file.

 

In perspective of VDS, each VDS has it's own VDS UUID, and the config backup of ESXi contains it. If you take a config backup just before reinstall, there is nothing to do for VDS after restoring ESXi.

 

In perspective of third-party software like Veeam, it depends. But at least, you should migrate and evacuate VMs from the target host to another host before reconfiguring the hardware, to avoid disruption. And you should reconfigure only one ESXi at a time to limit the impact on the system.

 

FYI, there is also the article about moving to another boot device in VMware Tech Zone (you may have already seen).

 

Moving off of SD Boot Media
https://core.vmware.com/resource/moving-sd-boot-media

[scale21]

Thanks for the reply. Im still not clear about the UUID.

IF i reload esxi, i will get a new uuid on that host.  Will the restore function from the backup file restore the old UUID to the host? It doesnt seem like it does according to these notes. 

Getting the right build number is easy as you can patch the newly installed host to the same patch/build number it was at prior to reload it. 

It says here that the uuid must match: 

> Note: When restoring configuration data, the build number of the host must
> match the build number of the host on backup file and UUID (can be obtained
> using the command "esxcfg-info -u") of the host should match the UUID of
> the host on backup file.

 

 

Also it says the following:

 

1. Once the ESXi has rebooted, run this command to restore the ESXi hosts configuration (replace <backup_location> with the path to the configBundle.tgz):

   # vim-cmd hostsvc/firmware/restore_config /<backup_location>/configBundle.tgz

Notes: 

• Add a 1 to force an override of the UUID mismatch.

For example: 

# vim-cmd hostsvc/firmware/restore_config 1 /tmp/configBundle.tgz

 

????? 

Do you want to force the UUID mismatch or not? This makes no sense. IF you are suspected to somehow keep the old uuid do you want to override? I read override to mean ignore the UUID mismatch and restore anyway using whatever the new UUID is. I wouldnt think you would want this. Or....does override mean replaced the mismatched UUID with the one in the backup and you do want to add the 1?

[Jangari]

> IF i reload esxi, i will get a new uuid on that host.

No. I think you mistake the hardware UUID for the ESXi's UUID. These two are different, not identical like the following:

 

The hardware UUID is not changed after reinstalling ESXi because it's in BIOS/UEFI. ESXi config backup uses the hardware UUID.

The ESXi's UUID is changed after reinstalling ESXi because it is assigned individual ESXi installation. But it is not used in config backup/restore.

If you extract configBundle.tgz, you can find Manifest.txt. You can see it contains the hardware UUID, not ESXi's system UUID.

If the UUID value in Manifest.txt does not match the hardware UUID, restoring backup is denied. In this case, you need to use force option. For example, the motherboard is replaced after the config backup was taken.

 

After restoring the config backup, ESXi's UUID is restored to the original one contained in the backup.

[scale21]

ah thank you. I did misunderstand.

 

I was thinking the UUID was part of the install and not part of the hardware. Yes...i will be restoring back to the exact same hardware in this case so that UUID should not change if it is bound to the hardware. 

I have confirmed that the UUID in the manifest matches and if that will get restored then that should work just fine. 

 

 

 

 

 

 

[scale21]

I backed up the host

reloaded; updated and tried to restore but the UUID changed. 

I had a look in the manifest file from my backup and that uuid is the one i documented before i started on this host. 

The host i just reloaded, patched and got ready for  restore has a completely different uuid than whats in the manifest file in the backup. 

 

Why? How do i get around this so i can restore? DO i force or use the ignore switch on restore?

 

I dont understand why the uuid would have changed. The hardware is the exact same hardware. 

 

[Jangari]

Which command did you use to check the uuid?

 

• esxcfg-info -u
• esxcli system uuid get

 

Please copy and paste the command with result you confirmed before and after reconfiguring ESXi.

 

And I didn't tell you that the uuid in Manifest.txt is what is restored as ESXi system uuid. That is the hardware uuid, and only used to check the consistency of the hardware uuid. The uuid that will be restored is the one in esx.conf, which is contained in the backup.

 

If you compare "esxcli system uuid get" with Manifest.txt, it's obvious that the these can't be identical because these are different uuids.

[scale21]

The command i was using to check the uuid in vmware is the following:

Get-VMHost <nostname> | Select Name,@{n="HostUUID";e={$_.ExtensionData.hardware.systeminfo.uuid}}

The prior uuid of this host was:

4973e799-3e01-7e49-a2be-2836dc6703d4

This was also reflected in the manifest.txt in the backup file from this host. 

Once i reloaded the host it wouldnt restore saying " fault.MismatchedBundle.summary"

If i check the uuid of the new host using the same command above it shows:

5c816f30-2717-e811-2018-03060000001f

 

If i run the command esxcli system uuid get on the newly loaded system it comes back as

637405cd-f099-6db8-c9c8-201806a501bf  

 

Are you saying that the "esxcli system uuid get" has to match whats in the esx.conf file in the backup? I thought the build number and the uuid were both located in the manifest file and if those didnt match, you wouldnt be able to restore.

 

Either way none of the UUIDs match on this host despite no hardware changes so is there a way to restore of the UUID doesnt match using the force switch  on restore? 

Oddly....i did another host just prior to this one and it worked just fine. Same hardware, firmware, versions and process. I cant explain why one worked an the other one changed its uuid. 

 

Is my next step to try:

vim-cmd hostsvc/firmware/restore_config 1 /tmp/configBundle.tgz

https://kb.vmware.com/s/article/2042141

This will force and override of the UUID mismatch. I Guess im not sure if this is ok to do or if it will cause issues.

[scale21]

update: I ran the command with the -force switch to ignore the uuid mismatch and that appears to have allowed for the restore. 

 

I still dont understand why this uuid changed but i guess a long as i am able to restore without issues thats all that should matter. 

 

[scale21]

Just reloaded another one and yet again the uuid is different. Same hardware. 

Looks like im going to have to use the force switch on most of them. Odd that i had one that worked properly and didnt change the UUID but i guess it may not be worth wasting time trying to figure out at this point. 

 

[alt_n]

You can just export ESXi VMs via ESXi client and then also import them to servers via ESXi client or vCenter.

If you want more convenient VM migration solution, you can also try Vinchin Backup & Recovery.