Windows 2003 Boot Drive Size Recommendations

[gicti]

Hi,

I'm looking for some help on figuring out what size most people are making their Windows boot drive (Drive C:) in a guest VM. I know it's a pain to increase the size.....

I'm building a Windows 2003 STD server to to host SQL 2005 STD. I normally install as much as I can on a second drive (Drive E:)

Thanx

[Texiwill]

Hello,

I tend to use 4GB as a minimum size, but I expand my drive up to 8 GB and make 2 partitions and have a C: and 😧 on the same 'disk'. But I am just testing software, it is the minimum I would install windows into.

Best regards,

Edward

[chandlm]

Our previous (physical) standard was 20GB and I've reduced that down to 12GB as a compromise. The only times I've run into a problem is when someone wasn't listening and installs software/data onto the OS partition instead of using a different partition.

Every once in a while I run into one that I need to increase the C: and I usually just use the Converter tool to do so...

[TomHowarth]

I tend to make my System Drive about 8Gb this allows for upgrades etc. some do smaller, others larger, when I do SQL I install the DB software in the C:\ and create a log partition\drive and a data drive

[RParker]

I hope you are talking about a separate drive not a partition right? At least make it a separate VMDK to put your data / logs / applications and maybe even another for swap. Differrent luns even for ultimate performance, even put vswp on another drive still..... seems like a lot, but if you are going to do it, do it right the first time.

For those of you counting that is 4 drives (4 distinctly different VMDK files). There are white papers on this for SQL performance on MS site, and they recommend this for physical machines as well, so VM's should not be any different.

That's how we setup, especially for SQL, spread out the love.... otherwise you may have performance issues.

[RJ162]

Just curious how you set up your LUNS and RAID Groups? I know you have separate VMDK's for OS, Data, Logs, etc, but when it comes to putting them on the physical disks, what do you guys generally do? It seems like it's quite easy to waste a lot of space if you don't plan what you are doing pretty carefully.

[J-D]

Be warned that if you use multiple vmdk's on more than 1 LUN, that you will end up with vmdk's with the same name.

This will result in failure of commiting snapshots of that VM. You will have to shutdown the VM and do the commit then.

I wish VMware would have allowed us to choose the name when adding an extra disk or just fixing this issue.

I would prefer to name the vmdk-files something MYVM_C.vmdk and MYVM_D.vmdk indicating the partition instead of MYVM.vmdk and MYVM_1.vmdk for example.

[RJ162]

When you say commit snapshots, do you mean delete them? Because that seems to work fine on multiple drives on different luns. What am I missing?

[geob]

I started using a 12GB C drive, but am having problems running out of space on VMs that have been around a while. MS hotfixes and other patches are eating up a lot os space. So recently started using a 20GB C drives, that should be good for a while.

I have found an easy way to resize the boot partition. Only takes a few minutes. Take a look at this link:

http://vmprofessional.com/index.php?content=2k3resize

[J-D]

yes, by saying "committing" snapshots I mean using the Delete button in the snapshot manager (don't know why they call it delete and not commit, it's confusing).

I know you can do most of them manually but I have encountered VM's who got a snapshot made by "Consolidate helper" and then you must shutdown the VM in order to get rid of that snapshot. The only way to avoid them is by using different names for your vmdk's. Check out KB article 5096672 for this:

I have a question too about the boot drives: in physical servers we normally put them on RAID 1 disks. The data will be on RAID 5 disks (unless it's a database). RAID 1+0 however causes you to loose much diskspace and I wonder if any of you are using RAID 5 for your boot drives. RAID 5 should be okay for this imho and doesn't waste that much space.

[TomHowarth]

I tend to use 10Gb as a base for my system drives, I just make sure that my clients remember to clean the disk of installed hotfixes

If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points

Kind Regards

Tom,

[gorto · Accepted solution]

Agreed.

8G-10G ought to be sufficient.

Also, make sure you don't use the default Windows page file size of x1.5 physical memory - 512M to 1G page file is sufficient as, if you're paging, then your performance will drop off radically in a guest.

[J-D]

I use 12 or 15 GB for the C-drive for most VM's. If it's a Citrix, most of the time it's 30 GB because of userprofiles (although they can be relocated).

About paging file: I prefer fixed paging files of at least the size of RAM you have assigned the VM. Windows will always put things in the pagefile even if it has enough memory. If the .vswp-file is being used by ESX for the VM, then performance will drop dramatically...the paging file in windows can be used but of course it shouldn't be used continuously.

[markzz]

I'll add my 2 bobs worth

I have of late changed tact on just how big should my System volume be based ona few factors.

1. How much ram is alocatted (therefore pagefile and memdump needs to be accomodated where ever possible on the System volume) Therefore this relates to which version eg, Standard or Enterprise

2. What apps will this server house and can they all be contained on another volume. "the vast majority of application including IIS can be installed to another volume if possible always try to reserve your system volume for system functions and don't alow log files to write to your system volume is possible"

3. Are you installing R2 SP2, If so add another couple of GB..

There are many other considerations which I'm sure we are all aware of.

What it comes to is :-

Standard Server System volume is 12GB, I think this will very shortly increase to 14GB as I want to ensure I can accomodate for a 4GB page file and have room for a membump if it occures.

Standard Server System volume when running apps which I can't move to another volume eg. SCCM, SQL etc. 18GB Volume

Standard Server System volume when running when running Citrix Metaframe 18GB Volume

Enterprise server System volume when no apps will be in the System Volume 18GB Volume (only accomodate for a 4GB page file on System volume, additional page files are located on other volumes)

Enterprise server System volume when apps will be in the System Volume, they will have 12GB of RAM 24GB Volume (only accomodate for a 8GB page file on System volume, additional page files are located on other volumes)

Then there's the whole x64 question..I'm working on this..

[RJ162]

Just FYI, on the pagefile, you really have the flexibility to move these off the OS drive if you want to save some space on that. I had been keeping my page files on the system drive with enough space to collect a full memory dump. However, unless you're really into analyzing page dumps, you really don't need a full memory dump for 99% of the situations. I've switched to doing just a Kernel memory dump, and so far on the few times I've needed to analyze the dumps it worked just fine. That way I can move the page file off of the windows drive. In my opinion, like other comments on here the page file really shouldn't be that huge anyway. Memory usage should definitely be watched a little closer in a VMWare situation so you don't run into paging -- you'll get much much better performance. And if you're not using the page file for paging or memory dumps, then it can be relatively small.

This is a great webcast for that sort of thing if you're interested:

Of course if you want to catch every possible scenerio, then maybe a full memory dump is in order.

Just my 2 cents.

[markzz]

There is merrit to what you have said RJ162.

When a blue screen occurs I analise it..Therefore it's necessary to get a full dump.

Regarding the page file location, It's just a standard that we locate the page file on the System drive, if you chose not to have it on the System drive you may not be able to get a full memory dump in the event of a blue screen. On the performance front, there is no performance benifit to putting a page file in a different volume yet on the same spindle..If you can't put your page file on a different spinfle (physical Disk) you have gained nothing

[SERussell]

Regarding the 20GB C: drive, have you found this to be the right size or could it be somewhat smaller? Boot drive size is being discussed by my team and I feel 20GB should be used instead of 10GB or 15GB. I need some real world number to back my claim.

Anyone?

Thanks.

[gorto]

Hey Markzz, you really shouldn't be getting Blue Screens in vitrual machines unless you're doing something wrong - so hence no need for any dump

[nabsltd]

For older Microsoft patches that you are sure you won't uninstall, you can always delete the "$NtUninstallKB######$" directories.

For more space savings, compress the "$hf_mig$" and "ServicePackFiles" directories (in the "WINDOWS" directory). I have heard conflicting reports about whether the second directory can be deleted, but the first definitely cannot be.