Current Instructions for moving VMDK to QCow2

[David Anderson]

There is lots of information out there about performing these steps, the difficulty is in find the most current and accurate specifically for ProxMox 5.2. I am running the most recent version (5.2) of ProxMox and testing out the ability of using it to replace my VmWare ESXi 5.5.0 server. There is much conflicting information about the process of moving a VMDK, I was hoping someone could point me to some updated information. The Wiki in ProxMox Documentation seems to be discussing version 4, and much of the internet information talks about a process of converting the hard drive to IDE first, installing virtio utilities or using other utilities - while others make no mention of it and just suggest running the conversion on the original VMDK file.

I have experimented with one, only to fail in a "Your PC ran into trouble" boot loop. Theses images are large and cumbersome, and I am hoping to get a process down so I can test more on the actual use of the VM - (e.g. if Windows AD survives the migration etc...).

Any assistance anyone can provide in the matter is appreciated.

All my VMDKs use Scsi disks, and I am suspicious that my last attempt failed at the process of copying the VMDK - think I may have gotten into a Veeam snapshot instead of the full VMDK. I am expecting the process would be similar to :

• Uninstall VmWare utilties from original vmdk
• Stop the VM
• Copy the VMDK and the xxx-flat.vmdk files to ProxMox
• run the qemu convert command on the VMDK file [not the flat] to create a single Qcow2 file
• Create a new VM in proxmox with identical hardware resources (e.g. 60G scsi hard drive, ethernet etc...) so that it will create a new VM ID and hard drive.
• Then replace the newly created Qcow2 file with the converted one from above.

Thanks in advance for any advice or suggestions.

 

[janssensm]

Drivers
There are several ways to get things done.
But I think the most important part is that you want to choose the scsi disk with virtio-scsi controller as soon as possible in this process.
The prerequisite for that is that Windows already has the virtio storage drivers installed or prestaged.
But there is a catch: installing the drivers is only possible if you have the hardware (virtual, so ESX or Proxmox) presenting this type of storage.
As far as I know, inside VMware you cannot present virtio storage. And inside Proxmox you have to be booted already into OS (or difficult steps within bootrepair...) to get them installed, which is why some people advise to go with ide storage for first boot, and a dummy virtio-scsi disk to get the drivers installed.

Preparing for prestaging drivers
What I recommend is to prestage the virtio drivers inside ESX, in the same step as you uninstall the vmware tools.
In order to do that you have to download the virtio drivers iso (stable, to be sure) and mount that inside your ESX VM.
You also need to get dpinst.exe which is inside Windows Driver Kit (WDK)

However DPinst was excluded after Windows 10 build 1511, (MS you are not helping ).
It's sad that I have to post a link outside MS domain to get the official download..
https://techjourney.net/how-to-down...1511-mct-iso-adk-sdk-wdk-hlk-mobile-emulator/
Look for WDK: wdksetup.exe
Install this somewhere and extract dpinst.exe.
You can find it in:

C:\Program Files (x86)\Windows Kits\10\redist\DIFx\dpinst\MultiLin

Prestaging divers
Inside your VMware VM, open exporer and go to this location, sort by date, most recent on top

C:\Windows\System32\DriverStore\FileRepository

If you succeed in prestaging your driver, you will find it on top of the list.

Now ensure that you have dpinst.exe inside your VM and virtio drivers iso mounted.
Use dpinst to prestage all needed virtio drivers.
Example:
To prestage a the virtio-scsi driver you could run (as local admin):

dpinst.exe /path d:\vioscsi\w10\amd64\

More command line options are possible:

dpinst.exe /?

Convert/migrate your VM
As you now have the virtio drivers prestaged inside your VMware VM, you can proceed in migrating as you want. You could follow the guide with qemu commands, you could also use clonezilla, many options.
Advantage is now you can boot your migrated proxmox VM straight ahead with virtio storage.
Windows should take care of correcting the bootloader. This process depends on what Windows version you are using. More recent versions are better at this.

 

[David Anderson]

OK, I just finished uploading a new copy of the VM - will head back into it and try again! Thanks for your quick reply and detailed response. I will let this thread know how it goes!

 

[akxx]

@David Anderson
i can "feel" very much with you ... i am in the same situation.
the only thing i figured out for me i, that it is the best for "moving" the (mostly large) vmdk file to an NFS volume, which is accessible from ESX and proxmox (and for sideloading tools also from my worksation) works best for transfering VMs.
if i will find a good solution for migrating the harddisk file i will exchange here

@janssensm
thanks for your description ... i try it and feedback here

@restofworld
would it be somehow helpfull to use VMDK harddisk type in a migration scenario?

 

[David Anderson]

I tested the steps, then went on VaCa so have not been able to post this response. I followed the steps, and got the drivers for the SCSI controller loaded into my VMDK before I copied it. When trying to boot it into ProxMox - I get the same results, the systems does not find the red hat driver and fails.

Here are the steps I did:

• Downloaded Stable virtIO.iso
  
• Downloaded dpinst.exe (from wdksetup.exe)
• Combined the two on a new DVD
• Launched a copy of the VM in VmWare Player (disabled network, and enabled DVD connected @ power on and inserted new virtIO/dpinst DVD)
• Boot VM - mine asked to upgrade vmdk tools, ignored
• open command prompt on VM
• D: - change to DVD
• D:\dpinst.exe /path D:\vioscsi\2k12r2\amd64\
• Next (in device driver install wizard)
• Would you like to install Red Hat VirtIO ScSi
  • Checked always trust RedHat
  • Click Install
• Completed ready to use
• Click Finish
• Double check C:\windows\system32\DriverStore\FileRepository\
  • sort by date
  • vioscsi_inf_amd64k... top of the list
• Opened Control Panel, Add Remove Program
• Uninstall VMWare Tools
• Saw Red Hat Driver Pack was installed
• Shutdown
• 7z vmdk files so I could move to ProxMox
• 7z x vmdk_file_prestage.7z
• qemu-img convert -f vmdk vmdk_prestage.vmdk -O qcow2 vmdk_prestage.qcow2

I rebuilt a ProxMox VM withth e same hardware specs as my VMware machine and replaced the qcow2 file with the one I created. I get into the same "your computer has run into a problem" - I went to the Command prompt on the troublesome VM and looked into the X:\windows\system32\DriverStore\FileRepository and the Redhat driver was not there. Mayb during the rescue and reboot mode, the system is using files from a different location or something?

 

[janssensm]

First I hope you had a nice hollidays.
Just tested myself, X:\windows\system32\DriverStore\FileRepository\ during WIndows recovery mode appears not to be the same content as the real disk content, so rather just a recovery image.

As you checked that the driver was installed and inside the driverstore, that should be OK.
Assuming you have virtio-scsi-pci in your VM config.
Just to double check, could you post your VM config?

If your config is fine, my guess would be something goes wrong inside the qemu-img conversion.

All my VMDKs use Scsi disks, and I am suspicious that my last attempt failed at the process of copying the VMDK - think I may have gotten into a Veeam snapshot instead of the full VMDK

Could be that this is where your issue starts.
To be sure that everything is inside one vmdk it's wise to clone your vmdk just after the last shutdown into a new vmdk file with vmware-vdiskmanager.exe
I don't think it's installed with Vmware player but you can get it with the VDDK apparently:

https://code.vmware.com/web/sdk/67/vddk

I would try parameter "-t 0"

 

[akxx]

i had some time today ... so i want to share my current progress

1. goal: migrate a ESXi hosted machine to PVE
(including deinstalling VMWare guest tools and installing PVE guest tools)

2. workflow (WIP):
2.0.0 make clone of VM for backup
2.0.1 prepare once: connect NFS store to ESXi and PVE hosts for fast filetranfer
2.1 start VM in ESXi
2.2 uninstall VMWare guest tools (reboot)
2.3 install spice-guest-tools-latest.exe OR install INF files from virtio-win.iso AND inject Mergeide
2.4 disable windows driver signature enforcement:

bcdedit.exe -set loadoptions DISABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING ON​

2.5 shutdown VM in ESXi
2.6 copy (or clone) VM to transfer storage (NFS)
2.7 create PVE VM with 2 disk: disk1->virtio sizeof vmdkdisk; disk2->ide sizeof vmdkdisk
2.8 remove disk2 file in shell
2.9 convert vmdk to qcow2: qemu-img convert -f vmdk /mnt/pve/vm-trans/vm1-c/vm1-c.vmdk -O qcow2 disk2.qcow
2.10 set disk2 as boot disk (PV gui Boot Order)
2.11 start VM in PVE
2.12 ... login ... open windows device manager .. enjoy installed virtio drivers
2.13 en able windows driver signature enforcement:

bcdedit.exe -set loadoptions ENABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING OFF​

2.14 shutdown
2.15 remove disk1 in shell
2.16 move disk2 to disk1 in shell
2.17 detach and remove disk 2 in PVE gui
2.18 set disk1 as boot disk (PV gui Boot Order)
2.19 start vm in PVE

3. open topics:
-> general: just tested with win8.64 ... test other platforms
-> step 2.0.1: filetransfer is fast, but images files look like NOT thin ... hm ... but qemu-ing makes it small again ... acceptable
-> step 2.3: to follow the idea of "guest tools" i prefer spice-guest-tools-latest.exe ... but driver iso gives more control ...
-> step 2.4: my observation: virtio drivers are not MS signed so they are not automatically installed

... is it possible to use @janssensm suggestion and combine it with disabling windows driver signature enforcement?​

-> step 2.7: need dummy virtio disk for virtio scsi driver installation; and ide disk for 1st time boot

... not the solution @David Anderson is looking for :-(​

-> step 2.9: i need to try to convert directly into block volumes
-> general: MS tools DISM allows to to more driver handling, but it works only in offline images ... i need to prepare an enviroment for this

i highly appreciate any optimization suggestions .

 

[David Anderson]

Was really pretty nice, went to the Upper Penn Mich for a family reunion.

VM Config for troublesome conversion VM:

root@pve:/etc/pve/qemu-server# more 103.conf
bootdisk: scsi0
cores: 2
ide2: none,media=cdrom
memory: 2048
name: svmnadPS
net0: e1000=76:CF:64:08:BA:9C,bridge=vmbr0
numa: 0
ostype: win8
scsi0: freeNASBackUp:103/vm-103-disk-1.qcow2,size=60G
scsihw: virtio-scsi-pci
smbios1: uuid=ccdcebbf-8b3b-4c29-8c05-310d75ed7265
sockets: 1
root@pve:/etc/pve/qemu-server#

I was worried about that (getting Veeam Snapshots) so this last one I ran a full Veeam Backup on the original, made sure all snapshots were consolidated before and used it - the veeam backup file was extracted with veeam.backup.extractor.exe and run inside of VMWarePlayer to do the pre-staging. Everything ran as expected and I did not see any noticeable issues.

 

[David Anderson]

Wow akxx great write up - thanks ill check it out and re-read in more detail. To be completely honest to all though, this is already way more trouble than I expected - might be better to just ride out our licenses till i'm ready to rebuild/upgrade the base OS. Given the way the industry (for us anyway) is heading to more Cloud based for larger critical systems and keeping a few non-critical systems in-house for basic LAN services, we may get to where these are needed less and less.

 

[akxx]

@David Anderson :
well i am also not happy with my "solution".
the main reason for all of this (from my perspective) is, that we do not have microsoft certified virtio drivers OR we have not the fitting redhat certificates in windows cert store.

so, i searched for one of these .. and found these snippets

my migration procedure is now shorter:

1. uninstall vmware guest tools in ESXi
2. install readhat cert
3. install virtio drivers
4. shutdown in ESXi
5. create VM in PVE (disk size same size as vmdk)
6. transfer / qemu-img VM disk to PVE
   (however you do it ... for me a NFS share accessible from ESXi and PVE seem to be the fastest method)
7. start VM
8. install guest tools

i the end migrating takes only a few minutes (plus transfer time )

i am wondering why Proxmox is not offering such a package , or do they - i just do not see it?

 

[user_ks]

Have also been struggling with similar kind of "basic functionality" stuff (euh shit?) with regards to PROXMOX VE.
I lost now already about 20+ hours of relentless research (seriously wasted time), without any decent explanation from PROXMOX documentation whatsoever.

This forum post is about one of the MOST BASIC uses cases for PROXMOX VE.
Being the transfer from VMWare virtual machines into the PROXMOX VE environment.
Alias: how to get .vmdk files swiftly/easily and effortlessly up-and-running into the PROXMOX VE environment.
(If the transfer already isn't swift and perfect, how to expect production-grade reliability afterwards ??)

I agree with @akxx who expresses in a very gentlemen way "i am wondering why Proxmox is not offering such a package , or do they - i just do not see it?" Right on spot.

After searching for MANY HOURS, sure that I did't find it easily, even at all.
(And this concerns, as said one of the more essential uses cases for PROXMOX VE)

Because I was so enthousiast about the PROXMOX VE, I even took a yearly subscription.
Little did I know that it would be so PAINFUL to simply install and get a .vmdk file up and running

Seriously disappointed and dissatisfied about the lack of ease-of-use !
The obvious basic use cases and scenarios should be offered as simple workflows out-of-the box.
Despite many great ICT evolutions and increased possibilities over the last decades, some people think that things better stay complex ... grrrrr

Apologies for my grunts.
And appreciation and gratitude for the question here and the write-ups by @David Anderson, @akxx and @janssensm.

 

[dcsapak]

here is the link to the official documentation: https://pve.proxmox.com/pve-docs/chapter-qm.html#_importing_virtual_machines_and_disk_images

there you will find the command 'qm importdisk' which imports also vmdk images

transferring files from/to a (proxmox/linux) server is a more general linux administration topic, nothing proxmox specific

 

[David Anderson]

I have been running a ProxMox server in my house now for a few weeks and it really is handling things well. I love that its web based (no client to install) it has seemed very stable and keeps chugging right along. The Documentation is out dated (pretty standard for Linux projects), but the forums seem to be kept up - blew my install apart trying to enable multiple hosts - and the forums got me back up and running with the same VM's I had before I blew it up. The backups work great, connects to my FreeNAS server pretty easily and for the simple functionality I require I think it will be fine product to use.

Having said that, I think it ridiculous the hoops you have to jump through just get simple email notifications working. I think many great Linux products tend to push things like this basic functionality off to the OS when they should incorporate it into their package. Out of the gate, this installed product should capable be sending notifications if I give it an email address to send to without me having to configure my server as a relay (Exim, Posfix, or other). Fighting old documentation and a hundred different ways to do it with a Google search.

As far as importing .vmdk files (the original reason for this post), I suppose that's only important to ProxMox developers if they want users to move from VmWare, OpenBox, etc... to their product - which I do not really recall reading about as a "awesome feature" of ProxMox product. On top of that, ProxMox is really just a wrapper/interface for QEMU system - trying to simplify the use of it - I think. The folks at VmWare want you to move to their product and have set up pretty basic ways for you to move your product to theirs. Me personally, I will continue to run VmWare in production and ProxMox at home - when/if I ever get to where I am in need of rebuilding the core virtual servers - I may consider building them on ProxMox server - but trying to move to ProxMox from anything and keep your servers original - after the numerous steps required it is not really something I want to undertake.

 

[Onitgroup]

Hello Everybody,
I'm new and very interested to PROXMOX, also in production environnement.

What about the free tool starwindsoftware converter to convert from vmware? Anyone tested IT?

 

[spirit]

simply use "qm importdisk"

qm importdisk 100 myfile.vdmk mytargetstore (--format qcow2)

       qm importdisk <vmid> <source> <storage> [OPTIONS]

       Import an external disk image as an unused disk in a VM. The image format has to be supported by qemu-img(1).

       <vmid>: <integer> (1 - N)
           The (unique) ID of the VM.

       <source>: <string>
           Path to the disk image to import

       <storage>: <string>
           Target storage ID

       --format <qcow2 | raw | vmdk>
           Target format

 

[Onitgroup]

Hello Everybody,
I'm new and very interested to PROXMOX, also in production environnement.

What about the free tool starwindsoftware converter to convert from vmware? Anyone tested IT?

So no one tested it ?

 

[David Anderson]

I read up on it, tried to download it, and never got the email link to down load so I could try it out. have older VM's I would love to move to Proxmox and see if I can drop VMWare for the little virtual environments I run.

 

[David Anderson]

simply use "qm importdisk"

qm importdisk 100 myfile.vdmk mytargetstore (--format qcow2)

       qm importdisk <vmid> <source> <storage> [OPTIONS]

       Import an external disk image as an unused disk in a VM. The image format has to be supported by qemu-img(1).

       <vmid>: <integer> (1 - N)
           The (unique) ID of the VM.

       <source>: <string>
           Path to the disk image to import

       <storage>: <string>
           Target storage ID

       --format <qcow2 | raw | vmdk>
           Target format

Tried this, (didn't see it before) so I used qm importdisk 105 server-flat.vmdk freeNASstorage --format qcow2 and I get:

Configuration file 'nodes/pve/qemu-server/105.conf' does not exist

 

[David Anderson]

So no one tested it ?

Finally got the download, its seems to work fine converting files (so does the command line) but it does not address the issue - the drive format is getting converted, but apparently the issue lies with the hard drive drivers available after the server tries to boot or something along those lines. So you have to jump through all these hoops to get it to work - open the original VM in VMware (and if your in production, first set up a second copy of things [a test environment] so you don't frag your live server) and replace the SCSI drivers with generic IDE, remove the VMWare tools, then pull down the server vmdk file, upload it to your Proxmox server, try converting it, boot it and hope the drivers you injected are available and it boots correctly or start over and try again. By the time you get done messing with all this stuff - you could have probably built a new 2012r2 server in Proxmox qcow2 format (or upgraded your server software to the newest version), recreated all the users and migrated the computers from the old Domain to the new.

The people that are really gonna be hosed and stuck with Vmware and have to continue licensing and trying to use it, are the folks that have applications frozen on some old version of Windows that the HR department just cannot live without, so your struggling to keep the friggen thing alive in its frozen state.