I just ran across a peculiar bug when you're using Windows Server Backup for virtual machines in Hyper-V. I was just doing some mind-numbing disk maintenance, reducing the capacity for a System Center 2012 R2 Operations Manager server. The general process for this goes...
- Open Disk Management (shortcut: right-click at the bottom-left of the screen in Server 2012/R2/Windows 8/8.1)
- Find the disk and volume that you want, right-click, and click Shrink Volume...
- Calculate how much space should remain after the shrink
- Subtract your desired new size from "Total size before shrink in MB" and put that in "amount of space to shrink"
- If you figure for 80GB and do 80 x 1024 to get MB, it won't come up round after the fact in Hyper-V, but it doesn't really matter
- Shrink!
- Once the process is done, shut down the server
And here's where I ran into the roadblock. There was a checkpoint (previously known as a "Snapshot") on the SCOM server that was created by a Windows Server Backup almost a week ago. That's not normal. And what do you know? I can't delete it. Or the subtree. And this is because the options don't appear in the right-side pane or with a right-click.
More often than not, it does what it's supposed to do:
- The Volume Shadow Copy kicks off when the backup process begins
- It takes a checkpoint of all the specified VMs, freezing that point in time, and the VMs go on about their business (albeit usually with massive lag from network or disk I/O)
- All of those checkpoints are compiled (with their parents) into one giant virtual hard disk (VHDX)... you know, sort of like the Power Rangers
- After an eternity, the file transfer finishes
- The service deletes the checkpoint
- The service stops
So what happened? Somewhere before the checkpoint deletion, the server went down, the backup was forcefully ended, the service died, etc. So it never got around to the deletion part.
It has to be hard to remove that checkpoint on purpose. If you're like me and completed addicted to checkpoints, I would inevitably delete that one on accident. The beautiful thing about the Volume Shadow Copy service is that it is designed to "just keep going." For that reason, it plays a huge role in the "Previous Versions" option for files, which has undoubtedly saved you or a loved one from devastation at some point in the past.
In this particular case and almost every other, the answer to this problem is PowerShell.
First things first, make sure to import the module:
Import-Module Hyper-V
(Super awesome tip: Can't remember the name of a PS module? Run Get-Module -ListAvailable and be amazed at how many exist that you've never heard of)
Next, run:
Get-VMSnapshot -VMName <name, like SCOM01>
Yes, it is "snapshot." No, there is not a "Get-VMCheckpoint" in the Hyper-V module. To make matters worse, it's a bit backwards when you're using the System Center Virtual Machine Manager shell.
It will return every checkpoint for that machine. If there is only one checkpoint, great!
If there is NOT only one, as in there is more than one, like this:
We have to narrow it down a bit. You can do this...
...where the question mark means "where" or "where-object". Alternatively, you could change that end part to:
? SnapshotType -eq "Recovery"
...but keep in mind that there might be more than one! The most surefire way to do it is to just copy and paste the checkpoint name and specify the -Name parameter.
Once you have it selected with that cmdlet, hit the up arrow key and slap a " | Remove-VMSnapshot" on the end. Bam. You're good to go. But now you see why the extra care needs to be made in the checkpoint selection.
I was then able to edit the disk...
...shrink the VHD...
(More often than not, you'll just want to pick the listed minimum.)
And hit Finish. Problem solved.
No comments:
Post a Comment