Converting Windows Machine to Proxmox with Multiple HDDs

[rbeard.js]

We have a few servers running on baremetal that we would like to port into proxmox. The issue Im having is that the VMware convert tool will merge the entire system into a single vdmk file that I can import. Thats been working great for machine with just a C drive. But these last few servers we have also have an E and F drive that I would like to import as separate vdmks.

Windows will only let you resize the disk that the unallocated space is next to in the native disk manager. If we make the entire system into a single vdmk and disk, we would only be able to resize the F drive without the use of third party tools and additional cost in some cases.

Is there a way with VMware convert or another tool to export a bare metal machine to vdmk and have a separate vdmk file for each disk?

The only idea I had was to just export the C drive and manually copy the E and F drive after making them in proxmox but this will probably destroy our offsite replication and mappings and permissions to a bunch of files. Not to mention that it would be time consuming to copy and place back.

Any advice would be greatly appreciated!

 

[sw-omit]

When we were migrating from ESX to Proxmox, we also had a fileserver with multiple, large disks that would take too long to "normally" copy during our maintenance time.
What we did for this was, on a system that already was on ProxMox and was also a domain-member, we attached new disks and used Windows own Robocopy with the below parameters to beforehand copy the entire disk over already, and then run the command again once a while during the preparation phase, before finally (once all users/services accessing the drive were shut down, do a final sync and then start to copy over the C-Drive. After the migration was done, we detached the drive from the temporary server and changed owner to the fileserver and started it.

All the shares/drive-maps, permissions, dates and everything stayed intact, the only thing that broke (which was caused by us first having to "online" the drive, so the drive was temporarily gone) was FSRM-quota's we put on folders, but since (except for like 1 or 2) all folders were using the same template, that was easily fixed as well. We could have probably even prevented this too by having FSRM not auto-start during the transfer.

I'm not sure how your replication works, so I can't vouch for that not breaking, for that I would need either more info, or you'd have to test, perhaps by re-using one of the old systems that ran bare-metal, installing all the "features" of the server on it with just a small amount of disk-usage, and test things out, would also verify that none of the other things break or if you need to do any extra steps.

Robocopy parameters used, ran on the temporary system as administrator.

robocopy \\old-server\E$\Shares D:\Shares /ZB /COPYALL /MIR /MT:8 /DCOPY:DAT /R:1 /W:1 /FP /NDL /NP /LOG+:C:\Temp\Robocopy-E.log /TEE

 

[rbeard.js]

When we were migrating from ESX to Proxmox, we also had a fileserver with multiple, large disks that would take too long to "normally" copy during our maintenance time.
What we did for this was, on a system that already was on ProxMox and was also a domain-member, we attached new disks and used Windows own Robocopy with the below parameters to beforehand copy the entire disk over already, and then run the command again once a while during the preparation phase, before finally (once all users/services accessing the drive were shut down, do a final sync and then start to copy over the C-Drive. After the migration was done, we detached the drive from the temporary server and changed owner to the fileserver and started it.

All the shares/drive-maps, permissions, dates and everything stayed intact, the only thing that broke (which was caused by us first having to "online" the drive, so the drive was temporarily gone) was FSRM-quota's we put on folders, but since (except for like 1 or 2) all folders were using the same template, that was easily fixed as well. We could have probably even prevented this too by having FSRM not auto-start during the transfer.

I'm not sure how your replication works, so I can't vouch for that not breaking, for that I would need either more info, or you'd have to test, perhaps by re-using one of the old systems that ran bare-metal, installing all the "features" of the server on it with just a small amount of disk-usage, and test things out, would also verify that none of the other things break or if you need to do any extra steps.

Robocopy parameters used, ran on the temporary system as administrator.

robocopy \\old-server\E$\Shares D:\Shares /ZB /COPYALL /MIR /MT:8 /DCOPY:DAT /R:1 /W:1 /FP /NDL /NP /LOG+:C:\Temp\Robocopy-E.log /TEE

Thank you for this! This is a pretty great idea and should let me minimize the downtime as well which is nice too!
I appreciate the input!
There is a file sync between each of the Domain controllers thats running from Task Scheduler as well as a shadowcopy job that runs every 30 minutes or so. If I disable them in task scheduler as I get everything in place, I think we should be good to go with this method!

 

[sw-omit]

Windows Shadowcopies you'll indeed lose the old versions for, but will be made anew again as well, but that is what backups are (/should be) for.
The file-sync with a task-scheduler task should indeed remain in-place, you'll just have to make sure the paths are the same.

Oh, and since I'm guessing that this machine is a domain-controller based on your note that the task is between domain-controllers, maybe good to make sure you have your DSRM-password before-sync, just in case.
If you also have RO-DC's still to migrate (or just in general for these DC's as well), maybe the tips of my post at [1] will help too

[1] https://forum.proxmox.com/threads/inconsistent-import-of-esxi-guest-to-proxmox.150936/#post-682795

 

[Taomyn]

I used CloneZilla when I migrated a bare-metal Windows 2022 server with several disks and cloned them across the network - I think it's mentioned as a solution either here on the forum or somewhere in the Proxmox docs. The server then powered up like nothing had happened - you do need to remember to install the VirtIO drivers on the original server first so that they are available when it's on Proxmox, and if you want can change the MAC address of any NICs the same.

 

[rbeard.js]

I used CloneZilla when I migrated a bare-metal Windows 2022 server with several disks and cloned them across the network - I think it's mentioned as a solution either here on the forum or somewhere in the Proxmox docs. The server then powered up like nothing had happened - you do need to remember to install the VirtIO drivers on the original server first so that they are available when it's on Proxmox, and if you want can change the MAC address of any NICs the same.

Did Clonezilla make a single file or was there a disk for each HDD?

 

[Taomyn]

It didn't make any files, it cloned the disks directly across the LAN to new ones on Proxmox.

 

[rbeard.js]

It didn't make any files, it cloned the disks directly across the LAN to new ones on Proxmox.

Well yeah Im sorry maybe I wasnt clear in my question.
Did you have a separate disk within proxmox for each HDD in the system? disk1, disk2, disk3 that are all attached to the vm in proxmox? I dont mean in the windows server.

 

[Taomyn]

Ah sorry, no - the physical was 3 separate disks, the VM was one virtual-disk on an SSD pool (the OS) and two virtual-disks in an HDD pool (storage)

 

[rbeard.js]

When we were migrating from ESX to Proxmox, we also had a fileserver with multiple, large disks that would take too long to "normally" copy during our maintenance time.
What we did for this was, on a system that already was on ProxMox and was also a domain-member, we attached new disks and used Windows own Robocopy with the below parameters to beforehand copy the entire disk over already, and then run the command again once a while during the preparation phase, before finally (once all users/services accessing the drive were shut down, do a final sync and then start to copy over the C-Drive. After the migration was done, we detached the drive from the temporary server and changed owner to the fileserver and started it.

All the shares/drive-maps, permissions, dates and everything stayed intact, the only thing that broke (which was caused by us first having to "online" the drive, so the drive was temporarily gone) was FSRM-quota's we put on folders, but since (except for like 1 or 2) all folders were using the same template, that was easily fixed as well. We could have probably even prevented this too by having FSRM not auto-start during the transfer.

I'm not sure how your replication works, so I can't vouch for that not breaking, for that I would need either more info, or you'd have to test, perhaps by re-using one of the old systems that ran bare-metal, installing all the "features" of the server on it with just a small amount of disk-usage, and test things out, would also verify that none of the other things break or if you need to do any extra steps.

Robocopy parameters used, ran on the temporary system as administrator.

robocopy \\old-server\E$\Shares D:\Shares /ZB /COPYALL /MIR /MT:8 /DCOPY:DAT /R:1 /W:1 /FP /NDL /NP /LOG+:C:\Temp\Robocopy-E.log /TEE

We are trying to implimint this in the same way you described but we are running into a bunch of permission issues. Our account doesnt have Backup and restore files user rights nor Auditing access event though its in the Administrators OU that has those permissions on the server.
We are also hitting access denied errors even though the target share has the same service account as the owner and on the share permissions.

Did you run into any of these issues?

 

[sw-omit]

We are trying to implimint this in the same way you described but we are running into a bunch of permission issues. Our account doesnt have Backup and restore files user rights nor Auditing access event though its in the Administrators OU that has those permissions on the server.
We are also hitting access denied errors even though the target share has the same service account as the owner and on the share permissions.

Did you run into any of these issues?

Probably a silly question, but just in case:
Even though you using a user in the administrator-group, are you also running the commandprompt and as such the command specifically "as administrator"?
I believe the only time I ran into these kind of issues (not sure about the exact message) was when I ran the commandprompt not as administrator (even though it was an admin-type user, but not the user "Administrator" (SID-500)

Also, could you copy and paste the exact command you are using (if the above does not apply/fix it)

 

[rbeard.js]

Probably a silly question, but just in case:
Even though you using a user in the administrator-group, are you also running the commandprompt and as such the command specifically "as administrator"?
I believe the only time I ran into these kind of issues (not sure about the exact message) was when I ran the commandprompt not as administrator (even though it was an admin-type user, but not the user "Administrator" (SID-500)

Also, could you copy and paste the exact command you are using (if the above does not apply/fix it)

Yup we are running the cmd as the domain admin. It should have all the access it needs for anything. I only added the /E to my command thats different than yours. Its usually upset about the COPYALL and ZB as those need Auditing and Backup rights specifically.

robocopy F:\ \\HDDMOVER\F /E /ZB /COPYALL /MIR /MT:8 /DCOPY:DAT /R:1 /W:1 /FP /NDL /NP /LOG+:C:\temp2\RoboCopy3.log /TEE

 

[rbeard.js]

Probably a silly question, but just in case:
Even though you using a user in the administrator-group, are you also running the commandprompt and as such the command specifically "as administrator"?
I believe the only time I ran into these kind of issues (not sure about the exact message) was when I ran the commandprompt not as administrator (even though it was an admin-type user, but not the user "Administrator" (SID-500)

Also, could you copy and paste the exact command you are using (if the above does not apply/fix it)

I got it working now.
Im not sure why I need to reboot the entire system whenever I made a permissions change for Auditing or Backup privileges but that seemed to fix it. I gave the drive owner those permissions and added it to the local administrators on the target PC. Rebooted and now it seems to be happy.
Thanks for the help!

 

[sw-omit]

I got it working now.
Im not sure why I need to reboot the entire system whenever I made a permissions change for Auditing or Backup privileges but that seemed to fix it. I gave the drive owner those permissions and added it to the local administrators on the target PC. Rebooted and now it seems to be happy.
Thanks for the help!

Good to hear.
Just a note, since you have the drive-root selected, it might complain about the "System Volume Information" folder, that is why in my example I used a sub-folder (and also because I have all my shared folders in that share folder)
Also, I take it you yourself made that "F" share? In case you don't know, Windows by itself always makes a default, hidden share for each drive, with <driveletter>$ as name, the $ making it invisible in the explorer, and that can (by default) can only be accessed by admins

 

[rbeard.js]

Good to hear.
Just a note, since you have the drive-root selected, it might complain about the "System Volume Information" folder, that is why in my example I used a sub-folder (and also because I have all my shared folders in that share folder)
Also, I take it you yourself made that "F" share? In case you don't know, Windows by itself always makes a default, hidden share for each drive, with <driveletter>$ as name, the $ making it invisible in the explorer, and that can (by default) can only be accessed by admins

Yeah It complained about the same thing for mine but has been copying the files otherwise. Permissions seem to be in place which was our main concern so Im not sure how much its going to effect the final result but I assume we will find out soon.

I didnt know that actually. Thats a good trick going forward! Thank you

 

[sw-omit]

It's usually best to not "mess around" with the SVI-folder, so if you have multiple folders in your F:\ drive and don't want to do one command per sub-folder, what you could do is add this to the command as well:

/XD "`$RECYCLE.BIN" "System Volume Information"
so in total:
robocopy F:\ \\HDDMOVER\F /E /ZB /COPYALL /MIR /MT:8 /DCOPY:DAT /R:1 /W:1 /FP  /NDL /NP /LOG+:C:\temp2\RoboCopy3.log /TEE /XD "`$RECYCLE.BIN" "System Volume Information"

 

[rbeard.js]

It's usually best to not "mess around" with the SVI-folder, so if you have multiple folders in your F:\ drive and don't want to do one command per sub-folder, what you could do is add this to the command as well:

/XD "`$RECYCLE.BIN" "System Volume Information"
so in total:
robocopy F:\ \\HDDMOVER\F /E /ZB /COPYALL /MIR /MT:8 /DCOPY:DAT /R:1 /W:1 /FP  /NDL /NP /LOG+:C:\temp2\RoboCopy3.log /TEE /XD "`$RECYCLE.BIN" "System Volume Information"

Awesome thank you Ill re run the copy with this to be sure we arent going to run into any issues down the line!

 

[sw-omit]

Awesome thank you Ill re run the copy with this to be sure we arent going to run into any issues down the line!

If you want to be extra sure (and got the time), you might want to wipe the disk (remove and re-add the partition or similar) to make sure it didn't messed with something already in there, although when I did it in the past without that option or a sub-folder, I didn't notice anything strange afterwards.

 

[rbeard.js]

If you want to be extra sure (and got the time), you might want to wipe the disk (remove and re-add the partition or similar) to make sure it didn't messed with something already in there, although when I did it in the past without that option or a sub-folder, I didn't notice anything strange afterwards.

That is exactly what I did. I wanted to make sure nothing was lingering and we have the time. Im going to do another copy after hours to aggregate the most current info before we virtualize the machine

 

[sw-omit]

Good luck with the move.

Also maybe you already know, but in case you don't; To verify that all files / connections is closed and everyone properly disconnected (except for you as admin), on the old server you can go to "computer management", "Shared Folders", "Sessions" or "Opened files", to check all remote connections.

Like I said before too, you might also want to stop/disable any services that might use those shares till your drive is properly connected on Proxmox again.