GPARTED (MOVE or RESIZE)...?

[Koldov]

After doing some cleaning up on my server I'm left with a bit of an issue which has me going round in circles and flip-flopping on which is the best approach...

 

To move forward I need to make some more space in the Hyper-V partition, unfortunately the partition to the right is massive and full of file share data that will be a major pain to move (plus I have nowhere to move it to easily)!

 

However, the D:\ partition to the left (which used to hold SIMS) can now be deleted and once the Hyper-V partition is large enough I plan to create a VM to hold the file shares data from the partition on the right (then I can delete it and expand to the right, however I can't do that until I expand the Hyper-V partition, so for now it has to be to the left), sounds a bit more complicated in theory than it should be, but I can't do the second part until I do the first...

 

 

Once the D:\ partition has been deleted, if I then use GParted to deal with the partitions, will it let me resize ('expand') to the left (and will it have to move the data to the start of the new bigger partition), if not do I have to 'move' the partition to the left (which will move the data anyway then expand to the right - which I would probably just do in Windows Disk Management to get the server back up ASAP)?

 

EDIT: After a bit more research in-between writing this post I think I will have to 'move' the partition to the left and then expand right (which means all the data having to be moved and the file index having to be re-written) something about the file map recording the start of a file from the beginning (starting sector) of the disk or partition (which will have changed)...?

 

This would mean filling up the new space on the left and then having to eventually write over the data on the right (and this can apparently take a very long time)... hopefully GParted just moves blocks to the beginning of the new from the beginning of the old?

 

Other options could be deleting the Hyper-V disks so there's less data to move and relying on backups to restore them after, or exporting/importing, or deleting everything and recreating the whole partition and recreating Hyper-V folder/file permissions, then Hyper-V machines and disks from backups etc...?

 

The other consideration is that there's a DC in the Hyper-Vs (one of two in the Domain) and it's the PDC, so I'd rather just have it 'down' for a few hours rather than restoring it from a previous backup (it's only really backed up for DR) unless I took them both down as soon as a backup was done...?

 

Edited January 25, 2024 by Koldov

[JRA]

Looks unenviable!

 

Have you done it yet? If so how'd it go?

 

If I were tinkering in that way I'd probably think about DD-ing the partitions off, re-partitioning the disk slightly over-size, then DD them back and resize with gparted. But to be honest the path of least resistance (from looking at it) would be gparted to move and resize as you planned. Usual caveats of "if it works right" and "so long as you have solid backups" and all that apply!

 

In fact as it's hosting VMs you need to run the DD dogleg option might not be the best thing.

 

If you HAVE done it now though did it go ok?

[Koldov]

Haha! No I haven't... I've decided this is definitely a 'half-term' kinda thing!

 

However, I have been testing (read mucked about) on a smaller test set-up and it seemed to work OK, so I am probably going to go with a different approach...

 

I have been shrinking other partitions so I think now I have some space to play with and now I have a cunning plan which is as follows:

 

 

FORMAT 'DATA1' (D:\) (OR JUST DELETE THE DATA ON THERE - NOT SURE IT MATTERS) - RENAME 'DATA1' TO 'HYPER'

 

SHUTDOWN VMs

 

DETACH HARD DRIVES FROM VMS AND MOVE TO OTHER DRIVES

 

SHUTDOWN THE HYPER-V SERVER MANAGER AND STOP SERVICES

 

USE ROBOCOPY TO COPY THE REMAINDER OF THE VM FOLDER & FILES (MACHINE CONFIGS ETC.)

 

robocopy V:\ D:\ /E /copyall /R:1 /W:1

 

DELETE HYPER (V:\) PARTITION

 

GIVE THE NEW HYPER DRIVE (D:\) THE LETTER V:\

 

EXTEND THE NEW HYPER V:\ PARTITION

 

RESTART HYPER-V SERVICE

 

MOVE THE DISKS BACK

 

ADD DISKS THROUGH HYPER-V MANAGER (SO THEY GET THE CORRECT PERMISSIONS)

 

START VMs

Once the new Hyperdrive is expanded, this should give me enough space to create another VM to do the FILE SHARES and this in turn will allow me to delete the 'DATA2' partition and expand the Hyperdrive even more, so I can expand all the Hyper-V disks and give them enough breathing room - and for Veeam to do its thing as it complained last time I had zero space left on the Hyperdrive (Hyper V:\).

Edited January 31, 2024 by Koldov