I have several appx. 6 TB of space I'm going to use to install several VMs on.

1.) Since I'm using Hyper-V 2012, I'd want to use the .vhdx format and not the older .vhd, right?

2.) Should I pre-plan what disk space I want to use for each soon to be VM and pre-create my .vhdx files in advance to use that space, or should I just create one big, 6TB .vhdx file and when I install each OS, simply choose what size I want the disk to be at that point?

3.) Keeping backups in mind, it seems like having indiviual .vhdx files for each OS will make backups easier, wouldn't it?

Thank you,

Ed

1.) The only reason I know of not to use .VHDX is if you might ever want to mount the .VHD in an older operating system and don't want to go through the conversion process first.

2.) Pre-planning is always good, but your choice is really between a single large NTFS volume or several smaller NTFS volumes to hold the .VHDX files of the VMs. Personally, I'd carve it up into smaller chunks but it's probably more because my thinking is old-school than because there's any really good reason. My decision would be influenced by whether or not the storage is internal or external. If it's internal, I'd be more inclined to just go with one huge NTFS volume for the VMs. If it's external, I'd be more inclined to go with multiple smaller volumes.

3.) You don't have a choice here. VMs can't share VHDX files... at least not while they're turned on... and having them try to share them in any other way is just begging for problems.

Following Eric.  Yes, use VHDX.  Few reasons not to.

Always give your VMs a cap.  Always plan your storage use.  Why give a VM OS a 128GB volume?  No reason to make it really big only to run into problems later.

You must have individual VHDX files for each OS of each VM.  You can link differencing disks from a root virtual disk - but that really only works when you quickly and frequently create and delete machines.  It does not work for long lived machines.

Thank you Gentlemen.

:-)

Since I have not done this before, I'm trying to visualize the steps I'll need to take.

I've, within my RAID controller card, created my 6TB logical partition. When I boot into Hyper-V and use diskpart, it does see the logical drive (Yay!).

Do I simply:

1.) Using diskpart, cut up my 6TB into the partition sizes that I ultimately want to house each VM OS?

2.) Create a .vmdx file within each partition using 100% of the available partition size? If so, how do I create a .vmdx file from the command line?

3) Launch Hyper-V Manager, create my first VM and then install into the new .vmdx file?

Yes? No?

Thank you!

Ed

Well, here's ONE way -- there are lots:

SELECT DISK #
ONLINE DISK
ATTRIBUTES DISK CLEAR READONLY
CONVERT GPT
CREATE PARTITION PRIMARY
LIST VOLUME
SELECT VOLUME #
FORMAT FS=NTFS LABEL=VMs QUICK
ASSIGN LETTER=V

Oops... there's more.

That makes an empty volume. Then I'd create a folder on it to hold the VMs. Use Hyper-V Manager to modify the properties on the host to target that folder. As luck would have it, I don't actually have Hyper-V Manager in front of me to get more detailed, but it's not hard to find them.

Then, just create VMs and be

Various ways you can spin it.  It is the number of possibilities that make it confusing.

Your host OS needs a volume.  Most likely local, not on the RAID.  Separate RAID 0 or 1.

How you RAID your physical disks is up to you (RAID card or Storage Spaces or a combination).  Sounds like you are already past this.

So, you have one big storage volume.  Create VMs and place then on it.  Create a folder for each VM on the volume and put the virtual disk for each VM in its respective folder.  Keep it neat.

You don't do step 2

You don't do step 1 (you can, but there is no benefit, at all).

Eric,

Thank you!

This would create (in my case) 1, 6TB partition, right? If so, that seems to run counter to what you normally like to do and what BrianEh (above) suggested as well "Why give a VM OS a 128GB volume?  No reason to make it really big only to run into problems later." or is Brian saying: when I install each OS, don't use the whole size available every time I create a VM, only use what space you need and no more. I misunderstanding you/he?

I *think* you're both suggesting the same thing; decide how large I want each VM disk size to be and create and format my partitions in advance before installing each OS (VM).

Yes? No?

Ed

You create your 6TB partition and that is what the host OS (Hyper-V) sees.

When you create a VM, you create a VHDX for it.  Each VM gets its own VHDX.  A VHDX is just a virtual hard drive.

Your VHDX has it's own size, completely unrelated to the physical size of the disk or partition. 

For example, a small server doesn't need 1TB+ of space, maybe only 30 or 40GB, so you create your VHDX with a size of 30GB.  This is simply just a file, i.e. server1.vhdx located on the host's 6TB partition.

No, and you need to start using very specific language rather than just 'partition' if you want to understand this - you could separate your disks on your raid controller into partitions, then partition each of those on the host os and create some vhd files and then partition those inside the guest VM - fun eh.

In short, don't create multiple partitions on the host (Hyper-V) level

On your raid controller you should create either:

1. one large volume (the whole 6TB); or
2. two separate volumes, one [A] small one (say 30GB - 100GB) purely for installing Hyper-V as the host OS, the second [B] for everything else - including the vhdx files

In the host OS (Hyper-V 2012) you should:

• Create a separate vhd for each vm you plan to create - if you went for #2 above, these will all be stored in a folder of your choice on [B], otherwise they'll be on the massive 6TB drive
• Ideally you would create a small (~30GB) vhdx for each OS of each VM and another separate vhdx file for the data / anything else (this is good architecture but not required, it's based on your usage - inside the VMs these would become your C: and D: drives)
• Attached the vhdx files to the VMs when you create them

Unless you are splitting RAID types, isolating specific hard disks for performance reasons, or planning to apply some variable security on the Hypervisor there is no reason to partition to more granularity than #2 above at the host-os level, you will create management overhead and reduce the flexibility to increase / decrease vhd sizes.

Eric,

Thank you!

This would create (in my case) 1, 6TB partition, right? If so, that seems to run counter to what you normally like to do and what BrianEh (above) suggested as well "Why give a VM OS a 128GB volume?  No reason to make it really big only to run into problems later." or is Brian saying: when I install each OS, don't use the whole size available every time I create a VM, only use what space you need and no more. I misunderstanding you/he?

I *think* you're both suggesting the same thing; decide how large I want each VM disk size to be and create and format my partitions in advance before installing each OS (VM).

Yes? No?

Ed

Well, I come from the days when we had to worry about things like allocation table and sector-per-track limitations. When I see a huge empty space, I mentally start carving it up because I remember not having an option. It's more Pavlovian than practical anymore. About the only reason I can think of to make that space smaller is because if you run a backup at the Hyper-V level, it's going to make a VSS snapshot of the whole volume. Is there really a problem with one big VSS snapshot versus one-at-a-time for smaller ones? Yeah, probably not. So again, my preference is unlikely to be relevant. Practically, I'd say if you're going to use all the space, use all the space at once and be done with it. All this part does is make a container for the .VHDX files. Just think of it like a bucket of VMs. You can put dividers in your bucket if you want to, but there's probably no benefit.

I avoided talking about the space to use for the Hyper-V installation because it sounds like you already did that separately. Yes, I would have Hyper-V in its own little space, probably around 50GB or so. Again, probably more Pavlovian than practical but it's not a habit I'm likely to break anytime soon.

With the VMs, go the other way. You're not going to use all the space at once, so design their .VHDX sizes more conservatively. Something like 40-60GB for the .VHDX to use as each VM's C: drive. Data volumes will have to be sized by role. I'm not sure anymore if there's really a good reason to even split OS and data inside a VM. Again, this is a relic of the days when we installed the OS on a RAID-1 array and the data on a separate RAID-5 or RAID-10 array. Now, all your .VHDX files are going on the same physical subsystem whether or not you break them up. Personally, I create 40GB C: volumes for all my virtual machines and make them dynamically expanding. They rarely pass 30GB used space. I choose between fixed or dynamic .VHDX files for data volumes based on the needs of the VM.

Remember that you can always make a .VHDX bigger as long as its containing volume has room.

Good stuff and lots of clarification...thank you all for the input and suggestions, I really appreciate your perspectives.

:-)

Ed

What I do think for a VM that it could be better to have 2 vhdx files. One for the system (OS) and another for the data. See it as C: and D: in the virtual machine itself. The main advantage of this is when something goes wrong with the Virtual Machine (the OS becomes corrupt for whatever reason). You can restore the C: must quicker because it should be way smaller, and leave the data untouched.

Yes, Brian, you are an MVP.  Good  "picture" BTW.  Time for threads to update for R2.  All should know MS has posted studies on size of volumes, and of course it depends on the hardware, so it's up to the hardware mfgs. to post specific performance specs.  I'd recommend you defer to the hardware mfgs.  All software mfgs. should defer to the hardware mfgs. to post "specific" numbers on "should I create one huge multi-terabyte VM volume" or "should I create multiple smaller volumes"....

Software would be nothing without hardware, and vice-versa......naturally if you have the latest 12 core blade system and a very fast SAN, you just may be able to work well with a 200 TB lun.  On the other hand if you have a test lab with desktop systems as test servers, 1 TB is maybe the most you can hope for.......

Depends on the hardware.  Consult your hardware mfg.

P.S. - that was on regarding the size of the volume.  VHDX has more resiliency than .VHD, look it up on Technet.

Each VM has at least one .VHD or .VHDX....many don't know that either one have "write-back caching" that can't be turned off --- except by putting database files (e.g., Active Directory NTDS, SQL Server) on a "pass-through" disk... this should be a MAJOR issue for MS....but it may be impossible to change, so I've always put the PDC root forest controller on a physical machine, not a VM....I would NEVER advise having a forest root DC on a VM.....