Disk resizing - mirror, copy, etc.

[Groundbeef79]

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:

1. Clone Volume on SAN, attach as second disk to VM.  F and G (or whatever) would be exact copy of C and D.  Delete D and F.  This creates two drives so we can resize them as needed.  Rename G to D.
   
2. Attach new volume to VM.  Using disk mirroring, duplicate D drive.  Destroy D and break mirror.  I’m rusty on this process as I haven’t had to do it since Windows NT.
   
3. Ghost to new volume on SAN, then re-Ghost back.  Fairly time-consuming.  Really don't want to do this.
   
4. Do a Vmware converter move.  A live conversion is not an option due to the amount of transactions this server receives.  Don't want to do offline, but if it is our only option then...
   
5. Mount new disk and robocopy D.  Delete original D and rename new D extend C.  Again, file level stuff and would need to be done in Safe Mode.
   
6. Create copy of VMDK and mount as another disk, similar to step 1.
   
7. Some other silver-bullet software that I don’t know about.
   

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.

[vmroyale · Accepted solution]

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!

[Groundbeef79]

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:

1. Perform a copy of the LUN on the SAN
   
2. Attach to VM (what about the VMDK? Won't it have the same signature/whatever as the first disk?  Not sure how to handle that.)
   
3. Stop applications and services during maintenance window
   
4. Robocopy changes to new disk
   
5. Delete D partition from 1st disk
   
6. Delete C partition from 2nd disk
   
7. Extend C
   
8. Rename new partition to D
   

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?

[kjb007]

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