{{ :supportukraine.gif|}}
====== Proxmox: Migrating VMware VCSA to Proxmox with Tux ======
{{en:tux.png |Hey, my name is "Tux"!}} **Did you ever wonder how you can migrate a VMware vCenter Server Appliance (VCSA) to Proxmox?**
\\ \\
Hey, my name is "Tux" and this tutorial will show you how you can migrate your VCSA instance to Proxmox.
\\
\\
----
\\
===== First thoughts =====
Beware: The following tutorial is based on a real existing example which values, especially //XML// code values, can slightly differ in your personal environment. Please find out for your own environment which //XML// code lines you have to adjust according to your personal settings!
===== Start of tutorial =====
Here are the steps to go:
- Export the whole VM from the ESXi web client, which will get you a couple of virtual disks (16 disks in my case) and a ''.ovf'' file, which contains the whole VM settings in //XML// format.
- Copy everything temporarly over to a local storage directory (in my case the root user's home directory ''/root'') on the Proxmox host, for example via [[https://winscp.net/eng/index.php|WinSCP]] (Don't delete the files yet from your local computer after copying over, as you will still need some of the virtual disk files later!).
- Now you have to do some preparation before the migration process: vCenter's default SCSI controller LSI logic parallel has a limitation of 15 virtual disk capability, but as already mentioned, vCenter 7 has more than 15 virtual disks attached to it, as shown in the following screenshot: \\ \\ [{{:proxmoxvcentermigration01.png?400|Amount of VCSA 7's VMDKs}}] \\ Therefore it has a second SCSI controller configured by default. The Proxmox import command on the other hand comes into stuggle when the original VM's virtual disks are attached to different SCSI controllers: As soon as the migration process reaches a virtual disk attached to a different SCSi controller, it will abort and result in the following error message: \\ ''error during import, cleaning up created resources...import failed - cowardly refusing to overwrite existing entry: scsi0'' \\ To prevent this issue, you have to exclude the virtual disks attached to the additional SCSI controller from the automated migration process by outcommenting everything related to those disks within the ''.ovf'' file (don't worry, we will import the remaining virtual disks later manually!). Technically it would not matter which SCSI controller's virtual disks you decide to exclude from the automated migration process, but obviously it would make sense to exclude the virtual disks from the SCSI controller which has the less amount of virtual disks attached to it as the automated migration process will leave you with less manual work afterwards. In other words: You have to check which of the two SCSI controllers has the lower amount of virtual disks attached to it and exclude those ISCSI controller's virtual disks from the automated migration process. You can check manually by using the ESXi web client which virtual disks are attached to which of the SCSI controllers: \\ [{{:proxmoxvcentermigration02.png?400|}}] \\ You can see on the screenshot above: \\ Virtual disk Nº 4 is attached on port Nº 3 of SCSI controller Nº 0 \\ and \\ virtual disk Nº 5 is attached on port Nº 0 of SCSI controller Nº 1. \\ After checking all virtual disks, in my case, I found out that SCSI controller Nº 0 had 14 virtual disks and SCSI controller Nº 1 had 2 virtual disk attached to them. So I decided to exclude SCSI controller Nº 1 its two virtual disks (virtual disk Nº 5 and virtual disk Nº 11 in my case) from the automated migration process. \\ To do so, start a Proxmox command line session, open the according ''.ovf'' file and look out for the according virtual disk entries of virtual disk Nº 5 and virtual disk Nº 11, which in my case were the following two //XML// code sections: -
0
Hard Disk 5
ovf:/disk/vmdisk5
14
3
17
and -
1
Hard Disk 11
ovf:/disk/vmdisk11
20
3
17
Now the important entries on both //XML// sections from above are the following: \\ • ''ovf:/disk/vmdisk5'' \\ • ''ovf:/disk/vmdisk11'' \\ • ''3'' → These are the matching entries which refer to the ''InstanceID'' of the SCSI controller the virtual disk is attached to. Not too relevant, but still for your information: In my case, the SCSI controllers in the ESXi Web UI were somehow numbered the other way round than they were within the exported ''.ovf'' file. In other words: SCSI controller Nº 0 in the ESXi Web UI was SCSI controller Nº 1 within the ''.ovf'' file and vice versa. Nice! Now based on the information we collected above let's move on and do an outcomment as follows on all relevant //XML// sections/entries, which in my case were the following (I won't explain too much at this point, please check by yourself why I have outcommented the according specific //XML// sections/lines, take a minute and you'll get the idea!) : and and and and and and Now safe the file, quit the editor and start the migration process by executing: qm importovf Working example: qm importovf 100 /root/vCenter-01.ovf local-lvm Now be patient as the migration process can quite take a while. It will create a new VM based on the information within the ''.ovf'' file and migrate the virtual disks in //RAW// format.
- In the meantime, on your local computer, you can start to convert the from the migration process excluded disks manually, for example by using the [[https://www.starwindsoftware.com/starwind-v2v-converter|Starwind V2V converter tool]] (That's the reason why you should still have kept the virtual disks files on your local computer as mentioned initially!). To keep things consistent, you should convert the remaining virtual disks also as a //RAW// destination format (After conversion feel free to rename the converted virtual disk files accoridng to the virtual disk file names which were generated by the automated Proxmox migration process.). Then copy the converted virtual disk files temporarly over to a local storage directory (in my case the root user's home directory ''/root'') on the Proxmox host, for example via [[https://winscp.net/eng/index.php|WinSCP]]. Now start a command line session on the Proxmox host and import those virtual disks one by one into the already existing VM by executing the following command: \\ \\ qm importdisk Working example: qm importdisk 100 /root/vCenter-01-10 local-lvm After successfully importing the virtual disks, they should appear as ''Unused'' in the VM hardware settings on the Proxmox GUI: \\ [{{:proxmoxvcentermigration03.png?400|"Unused" virtual disks}}] \\ To attach them to the according SCSI controller just double click the ''Unused'' virtual disks and configure them as required. \\ That's it! All virtual disks should have been migrated successfully now. Now before firing up your VM make sure you have configured the according VM's virtual CD-ROM and virtual NIC as you had it configured before on your ESXi host. On first boot, in my case, the VM did start to boot but aborted with a "CPU timeout" or similiar error message after a few seconds. I then forced the VM to power off, changed the BIOS from ''Default (SeaBIOS)'' to ''OVMF (UEFI)'', then back to ''Default (SeaBIOS)'', started the VM again and voilà, it booted up successfully! I am totally unsure why this problem appeared and I don't know if it has something to do with the VM's BIOS settings, maybe it would have been enough to just power off and power on the VM again without making any BIOS changes, I just wanted this to mention here.
\\
\\
===== End of tutorial =====
\\
\\
Appreciate my work? \\ [[https://www.buymeacoffee.com/fabioU|Buy me a coffee]] {{:buymeacoffee.png|}} or [[https://www.paypal.com/donate/?hosted_button_id=TH8Q3NTJCAJBA|PayPal]] {{:paypal.png|}}
\\
\\
**Source(s):**
\\
https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE#Virtual-to-Virtual_.28V2V.29
\\
https://forum.proxmox.com/threads/how-to-add-vm-from-raw-file-stored-on-disk.80391/
\\
https://dae.me/blog/2340/how-to-add-an-existing-virtual-disk-to-proxmox/
\\
{{htmlmetatags>metatag-robots=()}}