MIGRATE VMWARE ESXI VIRTUAL MACHINE TO PROXMOX VE
- Thread starter kazi
- Start date
Hi @kazi , there are a few things you need to review before migration. The list below is not exhaustive:
a) Review your Compute requirement and compatibility. Generally, because PVE is based on Linux, the compatibility is very wide, however exceptions can occur.
b) Understand cluster member requirements for PVE (at a high level an odd number of members is needed 3+)
c) Understand networking requirements and needs. PVE excels with LACP setup
d) Understand your storage needs and limitations: Specifically if you plan to re-use your existing investment in Dell iSCSI - your primary configuration option is LVM Thick. While it allows for Shared Storage and HA, it is not compatible with Snapshots or Thin Provisioning.
These are all included variants: https://pve.proxmox.com/wiki/Storage . Other options exist, such as Blockbridge.
e) After you install and configure your PVE cluster, the best approach is to migrate a few test VMs. High level of migration steps is covered here: https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE . There are many guides available on the net.
Perhaps even try to migrate your main VMs in an isolated network environment to get a feel for the procedure.
d) The main things to keep in mind when migrating : storage controller choice, network configuration transfer, CPU dependencies in the guest, boot device dependencies.
Keep an eye on the forum - we will soon be releasing a series of technical notes regarding ESX to PVE migration.
This list is just a high level overview and a lot depends on your particular setup.
PS a common question that is often asked is whether PVE has similar native technology to VMFS - it does not.
Good luck, feel free to reach out with any questions.
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
a) Review your Compute requirement and compatibility. Generally, because PVE is based on Linux, the compatibility is very wide, however exceptions can occur.
b) Understand cluster member requirements for PVE (at a high level an odd number of members is needed 3+)
c) Understand networking requirements and needs. PVE excels with LACP setup
d) Understand your storage needs and limitations: Specifically if you plan to re-use your existing investment in Dell iSCSI - your primary configuration option is LVM Thick. While it allows for Shared Storage and HA, it is not compatible with Snapshots or Thin Provisioning.
These are all included variants: https://pve.proxmox.com/wiki/Storage . Other options exist, such as Blockbridge.
e) After you install and configure your PVE cluster, the best approach is to migrate a few test VMs. High level of migration steps is covered here: https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE . There are many guides available on the net.
Perhaps even try to migrate your main VMs in an isolated network environment to get a feel for the procedure.
d) The main things to keep in mind when migrating : storage controller choice, network configuration transfer, CPU dependencies in the guest, boot device dependencies.
Keep an eye on the forum - we will soon be releasing a series of technical notes regarding ESX to PVE migration.
This list is just a high level overview and a lot depends on your particular setup.
PS a common question that is often asked is whether PVE has similar native technology to VMFS - it does not.
Good luck, feel free to reach out with any questions.
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
@kazi We posted the first portion of our study, in case you missed it:
https://forum.proxmox.com/threads/d...ciency-metrics-with-windows-on-proxmox.140825
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
https://forum.proxmox.com/threads/d...ciency-metrics-with-windows-on-proxmox.140825
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
When I did this, I used the VMware "ovftool" that's mentioned on the wiki migration page that @bbgeek17 referred to in his post. It worked quite well, and was snappy. I installed it on the Proxmox server, and connected back to vSphere to copy the VMs over.
The only brick wall I hit (with migration) wasn't a Proxmox problem... it was Windows 11's TPM requirement. Any Win11 machines just have to be rebuilt, as far as I know.
The only brick wall I hit (with migration) wasn't a Proxmox problem... it was Windows 11's TPM requirement. Any Win11 machines just have to be rebuilt, as far as I know.
Last edited:
Have you tried to add a TPM disk with pre enrolled keys to the Win11 VM? Or did you run into some other issue?
Dang. I didn't know this was an option. Everything I'd found led me to believe those machines would need to be rebuilt.
Unfortunately, I already rebuilt those three machines and consumed another three licenses. But I have three more with which to try. Are there any documentation sources for this process? Or is this just institutional knowledge?
If you create a new Win11 VM on Proxmox VE (select the correct guest OS in the wizard) it will automatically enable the TPM device and ask you where its state should be stored.
Additionally, if you haven't created it that way, you can add a TPM device later in the VM->Hardware panel.
Additionally, if you haven't created it that way, you can add a TPM device later in the VM->Hardware panel.
I’m confused, and this is likely my lack of knowledge on the topic. I thought that the TPM was machine-specific?
Like if I create the Win11 VM on my vSphere host (which actually has a physical TPM chip), that the VM is forever inextricably linked to that host.
Are you saying I could get the VMDK for that VM to Proxmox and create a TPM that would make it work? If so, how?
Like if I create the Win11 VM on my vSphere host (which actually has a physical TPM chip), that the VM is forever inextricably linked to that host.
Are you saying I could get the VMDK for that VM to Proxmox and create a TPM that would make it work? If so, how?
Only have a slight idea how it works with vCenter and I might be wrong. But AFAIU it is a vTPM. Meaning, the state is stored not in the physical TPM of the host, but in some other way. No idea how it is on a single ESXi/vSphere host.
On Proxmox VE the vTPM is not linked to the physical of the host but emulated to the VM. The docs can be found here: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_tpm
To create one, again, in the hardware panel of the VM, add a new device, choose "TPM state", select the storage where it should be stored, and on the next boot a TPM will be presented to the VM.
Whichever way TPM is implemented, migrating the state of the vTPM across different virtualization solutions will usually not work, as the implementations will differ. Therefore, for Windows, the situation is like when you move it to a different HW with a different TPM. Most likely the automatic decryption of Bitlocker will be affected by this.
In a migration scenario, you would have to disable bitlocker or enter the recovery key on first startup. In my tests, the VM booted fine after I entered the recovery key on the first startup after the migration.
I don't know much about dracut and if it might be the cause. But you can attach a live ISO to the VM and boot from it to investigate what is present in the disk image.
A quick search shows that it might be necessary to regenerate dracut. For example https://forum.proxmox.com/threads/dracut-error-after-converting-vmdk-to-qcow2.100733/#post-436040
I hope that helps
A quick search shows that it might be necessary to regenerate dracut. For example https://forum.proxmox.com/threads/dracut-error-after-converting-vmdk-to-qcow2.100733/#post-436040
I hope that helps
