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.
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:
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:
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.
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.
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