Attempting a Migration from VmWare ESXi 5.1 to Proxmox 6.2-6

[DAXQ]

Dunno why I am attempting this again, last time I just found it easier to recreate a new server on the new Virtual Environment - but I do want to try and get my head wrapped around this process if possible so I can move a different Windows based AD server without having to also move a bunch of other clients to the new server and rebuild a bunch of profiles. Anyway, I am following the instructions to export an OVF and have placed the OVF files on a FreeNAS file server. Now I need to move those files to an available storage path for the ProxMox server - would /var/lib/vz be an acceptable location to place these files for the import into the Proxmox server? Or would I be better off to NFS Share the files from the FreeNAS server, mount that NFS share on the proxmox, and then perform the import from the mounted file system?

Or should I scratch the OVF approach and try something completely different?

Any suggestions, recommendations or help with this matter is greatly appreciated.

 

[t.lamprecht]

Hi,

Now I need to move those files to an available storage path for the ProxMox server - would /var/lib/vz be an acceptable location to place these files for the import into the Proxmox server? Or would I be better off to NFS Share the files from the FreeNAS server, mount that NFS share on the proxmox, and then perform the import from the mounted file system?

The qm importovf command takes a new VMID and the path to the OVF as arguments, so the OVF manifest can be anywhere on the PVE host, locally or over a mounted share.

For example, getting a free VMID, importing the OVF and then importing a disk to the PVE storage with id "local" could look like:

VMID="$(pvesh get /cluster/nextid)"
qm importovf  $VMID /path/to/exported-manifest.ovf
qm importdisk $VMID /path/to/exported-disk.vmdk local

The disk will be add as "unused" to the VM, you can use the webinterface to add it as "used" one.

 

[DAXQ]

Great! So It seems it could be either local or mounted via NFS (just to access the files) - so I can now see the OVF file and the VMDK files on my ProxMox 6.2-6 server in the shell - they are mounted via NFS share from my OldFreeNAS server.

The VMID has kinda thrown me a bit.
If I follow the steps you've written in Bash: you've created a variable VMID which will get the next available ID (or I could just use the next number 101) and then execute the commands:

qm importovf 101 /mnt/pve/OldFreeNAS/SVMJJK1/SVMNJJK1.ovf
qm importdisk 101 /mnt/pve/OldFreeNAS/SVMJJK1/SVMNJJK1-disk1.vmdk local-lvm

Should put the moved VM in the local-lvm storage place and create the appropriate hardware.

Does this convert the vmdk to another format or leave it as VMDK?
Would like it to be in a more versatile VM file format if possible.

 

[DAXQ]

Is there really any negative impact (pros/cons) to converting or leaving it as VMDK?

And thanks for the reply - you guys are really pretty great and I've found ProxMox to be everything I need in a small simple virtual environment.

 

[DAXQ]

Well this is what I did - and thus far it is now running on the ProxMox server (without networking - which is great so i don't conflict with the original):

(This is a standalone Windows 2008R2 server with 8G Mem, cpu with 2 sockets 2 cores, default video, LSI Logic SAS, 80G SCSI hard Disk VMDK, CDrom E1000 network).

In VmWare on the VM - I ran the mergeide - not sure this did anything for me - but I had done it before I started following the steps in instructions.
Power the VM Down.
Used Export OVF (I used Folder)
Saved the exported files to my FreeNAS server.
Shared the OVF Files via NFS and then mounted that NFS share on my new Proxmox server.
On the ProxMox server I got to the shell and executed:

qm importovf 101 /mnt/pve/OldFreeNAS/SVMJJK1/SVMNJJK1.ovf local-lvm

I took quite a while, because I think it pulled the disk as well.

Then I ran
qm set 130 --bios ovmf
sed -i 's/scsi/ide/g' /etc/pve/qemu-server/130.conf

as instructed in the steps.

Booted the VM and it fell to a UEFI shell and wouldn't boot.

From the ProxMox GUI - I went to the Hardware and changed the BIOS from OVMF (UEFI) to Default SeaBIOS.

Booted again - and its running - seems just fine. I'll run it for a day or so without networking, and check some logs, see if anything odd happens. Then delete everything and try it again - maybe without the qm set 130 --bios ovmf step.

 

[t.lamprecht]

you've created a variable VMID which will get the next available ID (or I could just use the next number 101)

Yes, manually getting a free one works naturally too - this was just for convenience for people not bothering to lookup a free one themselves.

Does this convert the vmdk to another format or leave it as VMDK?

Normally the format is limited by the target storage, for example, with local-lvm you can only have "raw" images on a LV, on a file based storage you could have qcow2, raw or even vmdk. You can actually pass a "--format" parameter to specify the desired target disk-volume format. If that cannot work due to the storage not supporting it, you'll get an error.

Is there really any negative impact (pros/cons) to converting or leaving it as VMDK?

Different formats and storage-types have slightly different features and properties. But, with Proxmox VE you can simply move the volume to another storage and/or format, even live with a running VM, through the Webinterface "Move Disk" button (or qm move_disk).

Normally I'd say all formats work OK and if one would want the most and stable feature set I'd use qcow2 for file based storages and the others (LVM, ZFS, Ceph-RBD, ...) have only one choice and support most features anyway.

I took quite a while, because I think it pulled the disk as well.

Yes, true, if the disk is referenced and available it is already pulled in.

maybe without the qm set 130 --bios ovmf step.

Yes, if your VM isn't booting over UEFI but legacy BIOS (which is likely for a win 2008R2 one) you should simply to omit this step as the default is already SeaBIOS.

In general, see also our documentation regarding this:
https://pve.proxmox.com/pve-docs/chapter-qm.html#_importing_virtual_machines_and_disk_images

 

[DAXQ]

Well I am tickled to death at the progress made, and love that it's running. Thanks for all your help and Information. About my only concerns are:

The cloned server is no longer activated and I am hoping that is due to not having networking enabled - if that's the case no biggie.

Will this process work for an AD server or might there be some gotchas - gonna test that without networking this weekend.

Is the mergeide no longer needed? It wasn't mentioned in the instructions - has that been replaced sed command?

 

[DAXQ]

Whew ... finally had a chance to try this on a production system, was a bit hairy, but eventually worked out. One issue was my own stupidity - don't leave out the sed -i 's/scsi/ide/g' /etc/pve/qemu-server/vmid.conf command !

One other thing, while running the qm importovf vmid /mnt/pve/SVMNJJK1.ovf local-lvm command, there were times when my first ported VM stopped responding at all in it console. And twice, it just shut down completely - powered itself off. When it would do this, after powering it back up - the clock would be 6 hours in the future. So I had to reset the clock, I ended up configuring it use NTP instead of the CMOS clock, but it was very weird. After the import command finally finished, everything seems to be running fine, but that did concern me a bit. I thought I was over specked on the hardware for virtual machines I was running.

So even though I had to do the process twice for each Virtual machine and it took most of the day - right now, they seem to be running fine on Proxmox - and I was able to shutdown the old VMware servers by using the command above.

 

[Dominic]

One issue was my own stupidity - don't leave out the sed -i 's/scsi/ide/g' /etc/pve/qemu-server/vmid.conf command !

This is really important for Windows VMs as they usually don't have the required drivers. Please follow the Windows guest best practices to improve the performance of your VM after importing. I just added a big yellow note to that part of the wiki, so that those Windows steps are not overlooked.

Is the mergeide no longer needed? It wasn't mentioned in the instructions - has that been replaced sed command?

It was not required for the setups that I tested. There is now a sort of "migration archive" wiki page with all information that seemed relevant for only a few readers.

One other thing, while running the qm importovf vmid /mnt/pve/SVMNJJK1.ovf local-lvm. (...) . After the import command finally finished

Your first VM is stopping while the second one is imported?