14

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.

Improve this question
11
  • 2
    Looks like a bike shed to me.
    – Evan Anderson
    Nov 14, 2014 at 19:31
  • 2
    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.
    – Grant
    Nov 14, 2014 at 19:39
  • 2
    You're right. Template 2 doesn't segregate the VM's by folder, which is fine for the initial VHD(X) but could be problematic for subsequent VHD(X)'s unless you're conscientious about naming them.
    – joeqwerty
    Nov 14, 2014 at 20:03
  • 1
    How about a template with no space in the path?
    – user2813274
    Nov 14, 2014 at 22:01
  • 2
    @BenjaminPeikes Bike shed refers to Parkinson's law of triviality - en.wikipedia.org/wiki/Parkinson's_law_of_triviality
    – Grant
    Nov 17, 2014 at 16:42

3 Answers 3

Reset to default
13

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.

Improve this answer
3
  • 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.
    – Benjamin Peikes
    Nov 17, 2014 at 15:28
  • 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.
    – Benjamin Peikes
    Nov 17, 2014 at 15:35
  • @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.
    – Grant
    Nov 17, 2014 at 16:41
2

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.

Improve this answer
4
  • Isn't Template 1 what you get when you move a VM between hosts?
    – Benjamin Peikes
    Nov 17, 2014 at 17:33
  • Try it - it is not. For example the discs end up in a "Virtual Hard Disks" folder under the machine name folder.
    – TomTom
    Nov 17, 2014 at 18:03
  • 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.
    – Benjamin Peikes
    Nov 17, 2014 at 18:50
  • 1
    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.
    – Matty Brown
    Nov 23, 2014 at 20:36
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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .