8 ms·

So the Linux qemu-img tool can still convert VM disk images from .vmdk into formats compatible with all the other hypervisors. Is there something more to the p

So the Linux qemu-img tool can still convert VM disk images from .vmdk into formats compatible with all the other hypervisors. Is there something more to the process of VM migration from VMWare than just using this tool (and manually creating the proper virtual hardware profile in the new hypervisor)? Obviously the types of supported virtual hardware will be different between hypervisor types, but that's usually something that can be dealt with separately.

nn3 9d ago
Exactly. Either everyone is confused, or something is missing from the article.
rwmj 9d ago
The problem is how you access the disks that are sitting on a VMware server. VDDK allows you to connect and read them (in raw format, in fact) at a reasonable speed, and also understands sparseness and change block tracking.
- jasomill 8d ago
  I suspect the bigger problem is simply the fact that VDDK workflows are already defined and integrated into migration software packages. Otherwise, there are other options to copy virtual disks from ESXi hosts to other destinations that preserve sparseness and don't require shutting detaching or shutting down hosts using the disks, e.g., cloning a snapshot to an NFS server that supports sparse files.
justsomehnguy 8d ago
> Is there something more to the process of VM migration from VMWare than just using this tool (and manually creating the proper virtual hardware profile in the new hypervisor)? Yes? Do that for the hundreds of VMs, with a minimal downtime, bonus points for a dumb C-level on your neck. You would quickly learn what "just converting disk images" is not enough for moving between hypervisors. Just as an example: last year I moved a company with two Proxmox servers to ESXi. It took a 3 months and another server as a staging point. A minuscule in modern times 1TB+ VM took a whole weekend to be moved. Of course it didn't work in that time.
- dizhn 8d ago
  >A minuscule in modern times 1TB+ VM took a whole weekend to be moved Why?
  - justsomehnguy 8d ago
    Because it involved a full backup - which wasn't anywhere fast on Proxmox, reinstalling the host, a full restore and then tinkering with the famous "runs everywhere (and not Java!)" boot shenaningans of that flavour of Linux OS. And that was with the help of a backup-recovery solution which did support Proxmox, mere 6 months before that I would had stuck with an agent P2V migration of a VM to VM - which would had involved way more moving parts (can't P2V/V2V to a hypervisor which is not even installed yet) and more pain.
PunchyHamster 8d ago
Doing export manually vs automating it using their libs

nn3 9d ago

Exactly. Either everyone is confused, or something is missing from the article.

rwmj 9d ago

The problem is how you access the disks that are sitting on a VMware server. VDDK allows you to connect and read them (in raw format, in fact) at a reasonable speed, and also understands sparseness and change block tracking.

jasomill 8d ago
I suspect the bigger problem is simply the fact that VDDK workflows are already defined and integrated into migration software packages. Otherwise, there are other options to copy virtual disks from ESXi hosts to other destinations that preserve sparseness and don't require shutting detaching or shutting down hosts using the disks, e.g., cloning a snapshot to an NFS server that supports sparse files.

justsomehnguy 8d ago

> Is there something more to the process of VM migration from VMWare than just using this tool (and manually creating the proper virtual hardware profile in the new hypervisor)? Yes? Do that for the hundreds of VMs, with a minimal downtime, bonus points for a dumb C-level on your neck. You would quickly learn what "just converting disk images" is not enough for moving between hypervisors. Just as an example: last year I moved a company with two Proxmox servers to ESXi. It took a 3 months and another server as a staging point. A minuscule in modern times 1TB+ VM took a whole weekend to be moved. Of course it didn't work in that time.

dizhn 8d ago
>A minuscule in modern times 1TB+ VM took a whole weekend to be moved Why?
- justsomehnguy 8d ago
  Because it involved a full backup - which wasn't anywhere fast on Proxmox, reinstalling the host, a full restore and then tinkering with the famous "runs everywhere (and not Java!)" boot shenaningans of that flavour of Linux OS. And that was with the help of a backup-recovery solution which did support Proxmox, mere 6 months before that I would had stuck with an agent P2V migration of a VM to VM - which would had involved way more moving parts (can't P2V/V2V to a hypervisor which is not even installed yet) and more pain.

PunchyHamster 8d ago

Doing export manually vs automating it using their libs