vCenter

 View Only

 Can I import a VM from vCentre 8 to vCentre 7?

Bernard Thomas's profile image
Bernard Thomas posted May 15, 2024 09:33 PM

Hi all

We are currently in the process of migrating to a new data centre, which is running vCenter 8 U2b. Our existing vCenter is running vCentre 7 u3p. We have successfully carried out a test hot migration from 7 to 8, but we also want to know if we can migrate in the other direction, for whatever reason.

When I try to do an "Import VM" from VC 8 to VC 7, from the VC 7 instance, when I get to the stage of selecting a host esx to migrate to, I get the following message 

 "vCenter does not support hosts of this type ( )"

Is this a version issue? I have not been able to find out much search wise.

Thanks in advance

mmangold's profile image
mmangold

vCenter can only manage hosts of up to a maximum of its version—hence why we always update vCenter before ESXi during the lifecycle process: if we update ESXi before vCenter, then we are effectively cutting-off vCenter's ability to manage our newly-updated hypervisors. However, for your particular case, it sounds like the VM could be migrated back to the vSphere 7 instance, provided the virtual-hardware version had not yet been upgraded. The vSphere 8 instance would have been able to support vSphere 7 virtual-hw version VMs; however, the inverse is not true: therefore, once the initial v7 VM (virt-hw.v19?) migrated into v8 environment (virt-hw.v20?), vCenter 8 has no issue managing that VM. But if vCenter 8 upgrades the virt-hw.version to 20 on that VM, then vCenter 7 will not be able to manage it, because it only knows up to virt-hw.v19 VMs. Simply place on host that can be supported by vCenter 7, disconnect host from v8 environment once VM ha migrated to it- then attach that host back to vSphere 7 environment and migrate VM back to where originally desired. Move vHost back to v8 environment, if desired. Good luck.

Casey's profile image
Casey

You are going to want to downgrade the VM hardware version to 19 or lower. This can be down by powering down the VM, editing the vmx file, and powering back up. Make sure not to have any snapshots, but do have backups. You can test this by cloning one first. I do want to do this is not recommended, but I have had to resort to this to when hard times come knocking. 


1. An option I have not tried, but have read articles that says it should work is: 

  1. Power Off the VM: Ensure the VM is powered off.
  2. Export the VM: Use the "Export OVF Template" option in vCenter to export the VM.
  3. Import the VM: Import the OVF template into the target ESXi 7 host.

2. A less strenuous option is using VMware vCenter Converter which allows you to effectively migrate it to another host and select a hardware version in the process.


These last 2 boxes must be unchecked or the copy will fail


3. Downgrading VM Hardware version via CLI / VI. 

    1. Make sure the VM to downgrade is powered off.
    2. Enable SSH on the host and connect to it with a client such as putty. You can also use the local ESXi shell if that works better for you.
    3. Once connected to the host, change directory to the VM’s folder.

                                cd /vmfs/volumes/my_datastore/my_vm

              4. Edit the vmx file using vi and change the line “virtualHW.version” to whatever version you need. Refer to the table displayed earlier. In the screenshot I picked 12 as a random number.

Once in vi, hit “ ” to enter edit mode, hit “ escape ” to leave edit mode and type “ :wq! ” to save and exit vi.

The virtualHW.version key controls the VM’s compatibility level

The virtualHW.version key controls the VM’s compatibility level.”

    1. The VM is still at the same version in vCenter. We need to reload the vmx file to see the change. First, find the VM’s inventory ID (Replace “test-vHardware” with your VM’s name).

                                  vim-cmd vmsvc/getallvms | grep test-vHardware

6. Finally, reload the VM’s config file by using its inventory ID, in my case it is 11.

                                  vim-cmd vmsvc/reload 11

Changing the version with this method maintains the VM’s UUID




Let us know how it goes. Fingers crossed!

Bernard Thomas's profile image
Bernard Thomas

Hi all

Thanks for the answers.  Unfortunately it is not a VM hardware issue. The VM hardware version has not changed and is HW version 11

Thanks

Casey's profile image
Casey

Is it possible to catch some screenshots and post them in here. Sometimes and picture is worth a thousand words. Speaking of words, feel free to upload logs too for us to parse. The more details the better. 

mmangold's profile image
mmangold

Did you attempt my suggestion? Move the VM to a host that can be managed by either vCenter 8 (as-is), as well as v7. e.g.: any version ESXi on the host that is equal-to or less-than that of the vCenter-7. Then, once the VM is resident on that host, Disconnect it from vCenter8, followed by Connecting that ESXi over to the vCenter-7. Then you can migrate the VM back to from whence it originated. Lastly, Disconnect the ESXi from the vCenter7 and re-Connect back to vCenter8.

TX_Tundra's profile image
TX_Tundra

Are you using standard switches or vDS?  If you are using vDS and the switch in 8.x is a higher version, the VM will not migrate.  You could set up an ephemeral portgroup on the same vlan, power down the VM and try.  Or, create a standard switch to move the VM to, then migrate back to 7.x

Bernard Thomas's profile image
Bernard Thomas

Hi all

Again, thanks for the replies.


mmangold, your suggestion is indeed an option, but this is a fairly big migration and I need something a little more streamlined.

TX_Tundra, you may have hit the nail on the head. The VC 7 instance is using standard switches and the V8 is instance is using vDS. I havent seen anything in the cross vCentre migration docco that specifies switch type compatibility.

Casey, thanks for your detailed response. This is pretty much all I get when I try to do the import



mmangold's profile image
mmangold

Okay, then, in that case I believe you'd want to look into a feature called, 'Cross-vCenter vMotion'; it was mentioned briefly, yesterday, during Bob Plankers' VMUG presentation, 'How does vSphere Foundation Strengthen Your Security Posture?' 

The OP made it sound as if this was a small, proof-of-concept test involving only a limited number of VMs; hence, why I'd assumed a single host would achieve the desired outcome more quickly. Hopefully, XvCvM will be worth configuring the setup for your use case! Best of luck to you.