We have a vSphere 5 environment with quite a few servers. Initially, when I staged all of these VMs, they were staged virtual. No P2V migrations. This was also our first go-around with Server 2008 R2. So, me being the inexperienced VM admin that I am, I sized the disks too small. I also included the C and D drive on the same VMDK. Going forward, I will NEVER do this again. So my dilemma is I have several servers with a too small C drive on the same VMDK as their D drive. I'd like to be able to keep these servers up as they are super important. One of them should ideally be clustered, but the underlying database software (not any of the big names) does not support this. I've already resized several of the others as they aren't critical to stay up. I just attached another LUN, ghosted the disk to that LUN and resized it, then ghosted back to the original. Very time-consuming but it worked. So I've worked out a few ways that I think this might work:
I have a SQL server that I need to perform the same action on, but I can take it down on the weekend. I had thought my best option for the SQL server would be number 6, but for my original server that the question is about, I'm thinking that option 2 might be the way to go. Has anyone done either of these? My ideal solution would be some kind of live repartitioning, but I'm coming up blank when I look.
Hello.
I've done all of these options (except #2) at least once at some point! They will all work, and the key seems to usually be to find the fastest and most simple way to get it done. The SAN copies can be very fast, as can new VMDKs and robocopy. Any approach that allows you to seed data and then get the changes later is usually solid. This allows you to plan a smaller downtime, stop apps (get consistent state,) do the final copy/sync operation, make the changes and then test it. I don't know of any silver-bullet approach for this one.
Good Luck!
Hello.
I've done all of these options (except #2) at least once at some point! They will all work, and the key seems to usually be to find the fastest and most simple way to get it done. The SAN copies can be very fast, as can new VMDKs and robocopy. Any approach that allows you to seed data and then get the changes later is usually solid. This allows you to plan a smaller downtime, stop apps (get consistent state,) do the final copy/sync operation, make the changes and then test it. I don't know of any silver-bullet approach for this one.
Good Luck!
Thanks for the reply. I like what you said about seeding then getting the change data. So in my mind here's what makes sense:
Or am I better off copying VMDK files?
I do like this. Like you said, SAN copies are crazy fast, but let me throw another wrench in the gears. That first original disk is sized at 375 GB. Is there any easy way to shrink it to say 80 GB?
Converter is the only means here of shrinking the disk itself.
Another option you may have is to use converter on the C: drive itself, and then boot the new machine, and add the old drive. If all goes well, you can get rid of the old C: drive, and reclaim that space from windows itself.
Should work, but haven't tried it directly.
-KjB