Best practices for file layout in a Hyper-V server?

Question

We've got a Hyper-V server set up, and the layout of the files is inconsistent because it was set up by several people. Here are the two different "templates" that were used:

Template 1

D:\Hyper-V\Virtual Machines\MACHINE_NAME_1\Virtual Hard Disks\MACHINE_NAME_1.vhdx
D:\Hyper-V\Virtual Machines\MACHINE_NAME_1\Virtual Machines\GUID_1
D:\Hyper-V\Virtual Machines\MACHINE_NAME_1\Virtual Machines\GUID_1.xml

D:\Hyper-V\Virtual Machines\MACHINE_NAME_2\Virtual Hard Disks\MACHINE_NAME_2.vhdx
D:\Hyper-V\Virtual Machines\MACHINE_NAME_2\Virtual Machines\GUID_2
D:\Hyper-V\Virtual Machines\MACHINE_NAME_2\Virtual Machines\GUID_2.xml

....

and

Template 2

D:\Hyper-V\Virtual Hard Disks\MACHINE_NAME_1.vhdx
D:\Hyper-V\Virtual Hard Disks\MACHINE_NAME_2.vhdx

D:\Hyper-V\Virtual Machines\GUID_1
D:\Hyper-V\Virtual Machines\GUID_1.xml
D:\Hyper-V\Virtual Machines\GUID_2
D:\Hyper-V\Virtual Machines\GUID_2.xml

Template 1

The argument made FOR Template 1, was that when you do an export of a VM the export creates a folder with the machine name, puts separate folders for the disks and vm. You can then simply point to the machine directory when you run an import.

The argument AGAINST this template style is that it doesn't make sense for there to be a directory called Virtual Machines if there is only one file. The other argument against is that it appears that that Hyper-V server itself seems to expect that all hard disks are in one folder, and all the Virtual Machines are in a different folder. i.e. it doesn't create separate folders for each VM (execept for the ones nameed by GUID in the Virtual Machines directory)

Template 2

The argument FOR Template 2 is that it seems like that is what Hyper-V expects the layout to be.

The argument AGAINST Template 2, is that you can't tell which Virtual Machine files are associated with a specific machine unless you look inside the xml files.

I'd love to hear about any pitfalls to either layout.

Solution 1

You really, really want to be able to easily identify which files belong to which virtual machine. Even if you lose access to the Hyper-V console.

This comes up when trying to restore a VM from backups. Or when Hyper-V forgets about all of your VMs and you need to import them. Or the VM config files are corrupt, and you have to recreate the VM and point at the old hard drive files (which you now can't identify, since your config file is corrupt). Or you just want to quickly check how much disk space each VM takes up. Or you need to restore from backups where you can see the filenames, but not easily read the XML files without going through the entire restore process first.

Given that, I'd go for something similar to Template 1, where there is a folder for each VM - but leave out the "Virtual Machines" and "Virtual Machine Hard Disks" subfolders - just put all the files related to a VM in a folder with the VM's name.

You also don't need Hyper-V\Virtual machines - pick one of those labels, you don't need both.

So:

D:\Virtual Machines\MACHINE_A\GUID_1.xml
D:\Virtual Machines\MACHINE_A\Machine_a_OS.vhdx
D:\Virtual Machines\MACHINE_A\Machine_a_Data.vhdx

D:\Virtual Machines\MACHINE_B\GUID_2.xml
D:\Virtual Machines\MACHINE_B\Machine_b_OS.vhdx
D:\Virtual Machines\MACHINE_B\Machine_b_Data.vhdx

etc.

Or you might decide you don't need the filenames to match the virtual machine - the folder name is sufficient. Naming it this way would make it easier to clone a VM without having to worry about renaming it's files:

D:\VMs\Machine A\GUID_1.xml
D:\VMs\Machine A\OS.vhdx
D:\VMs\Machine A\Data.vhdx

D:\VMs\Machine B\GUID_2.xml
D:\VMs\Machine B\OS.vhdx
D:\VMs\Machine B\SQLData.vhdx
D:\VMs\Machine B\SQLLog.vhdx

The main takeaway here is to organize the files so that by looking at nothing else but the file structure, you can tell what VM each file belongs to, and what that file is for.

Solution 2

You need to do template 2 to separate coupling for virtual machine parts from storage concerns. I.e. one VHDX for a VM might go for a performance volume, another VHDX for the same VM is more concerned with capacity - and all may be with differences in resiliency.

So you will not be able to do template 1 unless you also introduce into the file structure layout the complication of mapping different storage locations into the coupling for the virtual machines file parts.

Thus:

TEMPLATE 2

Template 2 - Here storage management takes precedence over namespaces layout (meanwhile, namespace layout is handled in the UI for managing the VM ... i.e. some parts of the VM may not even be local but be in the cloud etc using for instance the storage bus)

... managing different concerns in storage management:

D:\Storage\Pool1\Hyper-V\Virtual Hard Disks\xxx-xx-xx-System-01-Prod.vhdx

D:\Storage\Pool1\Hyper-V\Virtual Hard Disks\xxx-xx-xx-Data-01-Prod.vhdx

D:\Storage\Pool2\Hyper-V\Virtual Hard Disks\xxx-xx-xx-Data-02-Prod.vhdx

D:\Storage\Pool3\Hyper-V\Virtual Hard Disks\xxx-xx-xx-Recovery-01-Prod.vhdx

D:\Storage\Pool1\Hyper-V\Virtual Machines\GUID_1

D:\Storage\Pool1\Hyper-V\Virtual Machines\GUID_1.xml

D:\Storage\Pool1\Hyper-V\Virtual Machines\GUID_2

D:\Storage\Pool1\Hyper-V\Virtual Machines\GUID_2.xml

TEMPLATE 1

To do this mapping in template 1 - where namespace concerns in the file system (aka a pseudo provisioned ui) takes precedence - while maintaining storage concerns:

D:\VMs\xxx-xx-xx-01-Prod\xxx-xx-xx-System-01-Prod.vhdx > (linked to) D:\Storage\Pool1\Hyper-V\Virtual Hard Disks\xxx-xx-xx-System-01-Prod.vhdx

D:\VMs\xxx-xx-xx-01-Prod\xxx-xx-xx-Data-01-Prod.vhdx > D:\Storage\Pool1\Hyper-V\Virtual Hard Disks\xxx-xx-xx-Data-01-Prod.vhdx

D:\VMs\xxx-xx-xx-01-Prod\xxx-xx-xx-Data-02-Prod.vhdx > D:\Storage\Pool2\Hyper-V\Virtual Hard Disks\xxx-xx-xx-Data-02-Prod.vhdx

D:\VMs\xxx-xx-xx-01-Prod\xxx-xx-xx-Recovery-01-Prod.vhdx > D:\Storage\Pool3\Hyper-V\Virtual Hard Disks\xxx-xx-xx-Recovery-01-Prod.vhdx

D:\VMs\xxx-xx-xx-01-Prod\GUID_1 > D:\Storage\Pool1\Hyper-V\Virtual Machines\GUID_1 D:\VMs\xxx-xx-xx-01-Prod\GUID_1.xml > D:\Storage\Pool1\Hyper-V\Virtual Machines\GUID_1.xml D:\VMs\xxx-xx-xx-01-Prod\GUID_2 > D:\Storage\Pool1\Hyper-V\Virtual Machines\GUID_2 D:\VMs\xxx-xx-xx-01-Prod\GUID_2.xml > D:\Storage\Pool1\Hyper-V\Virtual Machines\GUID_2.xml

Solution 3

I like none.

Because none of your templates is stable in case you move a VM.

I would - and I do that myself - use a folder structure identical to the one you get when you mvoe a VM between hosts. That way nothing changes when - you move a VM between hosts.

Comments

[Spence]

Looks like a bike shed to me.

[joeqwerty]

This seems like a subjective question. I don't think it really matters from a technical perspective as long as Hyper-V knows where each VM's files are. Organize it however it suits you best.

[Grant]

I disagree. From experience, there are some good technical reasons to have a naming convention where you can identify which disks belong to which VMs from outside of the Hyper-V tools. One of his options doesn't allow you to do that easily - or at all, if the hyper-v XML files are corrupt, which can happen.

[user2813274]

How about a template with no space in the path?

[Srikanth]

@user2813274, What's wrong with a space in the path?

[Srikanth]

@EvanAnderson, what do you mean by bike shed?

[user2813274]

Because of how horribly inconsistent it is Across different platforms.

[Grant]

@BenjaminPeikes Spaces often require quoting in command line parameters and scripts - its not a big deal, but if you can save yourself the hassle...

[Grant]

@BenjaminPeikes Bike shed refers to Parkinson's law of triviality - en.wikipedia.org/wiki/Parkinson's_law_of_triviality

[longneck]

I don't know if it applies in this situation, but "Template 2" is the way that a stand-alone Hyper-V server will store VM's by default, and "Template 1" is the way a clustered or VMM managed Hyper-V server will store VM's.

[Srikanth]

I have been leaning towards the layout you propose. One thing about this particular layout I don't like, is that it uses the machine name in both the folder structure and the file naming convention. This means you can't simply copy a folder of a machine to make a new one.

[Srikanth]

One argument I've heard, is that you can tell which files belong to which virtual machine by looking into the xml files for each GUID. Even though it's definitely useful to have an easy to understand naming convention, it completely falls apart if someone doesn't follow it, even once. It's like having comments in code that don't match the code anymore. Since all of the information about the machine is in the xml file, I'm wary of relying on naming of folders and files to figure anything out.

[Grant]

@BenjaminPeikes Relying on the XML files to match files to VMs is risky. I have had cases where either through accidental deletion or data corruption the XML files were gone or unreadable. Also, it's just plain faster than matching GUIDs up. But I agree you don't necessarily need to use the VM name in the filename, just the folder if you prefer. Just make sure that - by looking at nothing but the file structure - you can tell which files belong to which VM and what purpose they serve.

[Srikanth]

Isn't Template 1 what you get when you move a VM between hosts?

[TomTom]

Try it - it is not. For example the discs end up in a "Virtual Hard Disks" folder under the machine name folder.

[Srikanth]

that's what my Template 1 does. Each machine has it's own folder, and in each of those folders are a Virtual Machines folder and a Virtual Hard Disks folder.

[Matty Brown]

Is there some way of getting Hyper-V to use the structure that you've described by default when a VM is created, @TomTom? I like putting my VM's under a folder of their own. But each time, I end up creating the VM then moving it straight after to get the folder structure I want.