By now a lot of you will have heard that in Windows Server 2016 virtual machines have a new configuration file format. The new configuration files use the .VMCX file extension for virtual machine configuration data and the .VMRS file extension for runtime state data. These are binary, so no more xml and VSV/BIN files.
The new format was designed with a couple of goals in mind:
- Increase the efficiency of reading and writing virtual machine configuration data.When you start scaling to thousands, tens of thousands and more VMs the overhead of parsing XML begins to weigh on performance.
- Reduce the potential for data corruption in the event of a storage failure. It has logging included. So after making the virtual hard disks (thanks to VHDX introduced in Windows Server 2012) more resilient to corruption the configuration files have followed.
- Perhaps the reason with the least emphasis but it also prevents us from mucking around in the XML files. Yes we didn’t just read them. We edited them, we “experimented”, we copied them and fix the security settings … all god when you accept the big boys rule of ”it’s your responsibility and not supported” but I’m afraid Microsoft support got a fair share of calls related to this.
Note: With PowerShell & Compare-VM we can still correct inconsistencies on a file. That’s what Compare-VM is all about => getting the info you need to correct issues so you can register or import a virtual machine.
Let’s take a peak under the hood at a VMCX file. As you can see it’s not human readable.
I’m fine with that as long as I have the tools I need to get the information I need. The Hyper-V Manager GUI is one of those tools. But it doesn’t always show me everything I might need. An example of this is when things have gone wrong and I need to manually merge snapshots. There is valuable information in the VHDX/AVHDX configuration in the virtual machine configuration that gives me clues and pointers as what to do.
So how do I deal with reading Windows Server 2016 Hyper-V configuration files now? It was one of my first questions to the Product Group actually. The answer I got from Ben Armstrong was: PowerShell and Compare-VM. He has a blog post on this here.
The gist is that we create a temp VM object using Compare-VM en get the configuration information out that way.
$TempVM = (Compare-VM -Copy -Path $VMConfig -GenerateNewID).VM
$TempVM | select *
In my example I used a VM with some checkpoints and as you can see we can get the information on the parent checkpoint name (“HELLO”) and everything else we desire.
By querying the $TempVM a bit more we get the hard drive info and see which is the current AVHDX we’re running on. 
Hope this gives you some pointers.
I still can’t believe that they did it. I’m used to quickly glance into XML files almost every other time, it was very convenient.
XML is causing bottlenecks? Fine, switch to JSON then or even good old INI files. Resilience? Don’t we have ReFS for that?
I’m curious, is there any other virtualization solutions using binary configuration formats at all?
I don’t get this. How can xml cause bottlenecks? The vm configuration file is is some KBs in size. How can that cause any bottleneck anywhere when it’s not even updated that much during usage? If performance is the reason, they must give much more compelling evidence to support this than simply saying it’s faster – specifically, what use case is slower with XML (in any measurable way)?
I think that this idea arose not from the fact that it will enhance parsing and scalability, but to make difficult to an Admin to play easly with these configuration files. Like beatcracker sad, they could use Json instead. Anyway, it’s already done, and we have to adopt it. But in the meanwhile, i think that it will be tools that convert this file to a readable format, and who knows, vise versa too.
These are the various reasons given by MSFT during presenations (TechEd/Ignite/TechNet). I agree it would be nice for Microsoft to elaborate on these.
I haven’t tested it myself, but what does the migration scenario look like, if any at all, for folks moving VMs from 2008 R2, 2012, or 2012 R2 look like?
From 2008 R2 to 2012 R2, it’s not even an option to import a VM exported from 2008/R2, you have to use different approaches to migrate.
Depending on what version you’re at there will be different scenarios. The Migration Guides should be out by RTM like they have them for Windows 2012 R2 (like the cluster upgrades. https://technet.microsoft.com/en-us/library/dn486772(v=ws.11).aspx
Great post, I have a VM and want to read the names of the virtual switches that the Network Adapters were connected to. I can see there is a “NetworkAdapters” property of the temp VM – but when I look inside these objects the “Switch Name” is blank. I know the information is in the file somewhere – when I try and import through GUI, it displays the names. Any ideas?
once you got your $TempVM variable filled use $TempVM.NetworkAdapters to grab all NIC of your VM …. it’s in there you’ll see
once you got your $TempVM variable filled use $TempVM.NetworkAdapters to grab all NIC of your VM …. it’s in there you’ll see
Ye I tried that, but the SwitchName properties are blank 🙁
http://imgur.com/a/3fX5G
So does that VM have vSwitch assigned or not? What does Get-VMNetworkAdapter MyVM | fl * return for the switchname?
How does one get the last powered off date for a vm from this new vmcx format? In the xml format you could look into the last_powered_off_time node. It was that easy.
So viewing a .vmcx file is one thing. But what if we need to edit one? I know, I know… MS says we’re not supposed to BUT… there are some situations where making minor tweaks would be pretty dang helpful.
Anyone?