Is compacting a Hyper V virtual machine VHD file a safe operation

hyper-vvhd

Is compacting a Hyper V VHD (Server 2008 R2 Host) a safe operation? I compacted a Server 2008 Std 64 Bit virtual machine's boot volume and it ended up being about 500 Mb smaller. The VM was shut down at the time. However over the next 10 days that machine seemed to lock up in very strange way approximately every 2 days but not a consistent time.

It would stop responding to the network, but it was sometimes possible to get in on the console directly on the Hyper V host. If the console was locked it would not respond to ctrl-alt-delete but the easy access button would hilight and unhilight with a mouse-over. And it could be clicked and the window opened but would not respond to anything else. On one occasion the console was not locked and the start menu could be used, and the right-click menu for icons would pop-up. However there was no response to starting an application, or clicking on menus. It also would not shut-down even from the the Hyper-V manager and had to be powered off and on. After a power off and on it worked normally sometimes for a few days.

There are no useful messages in the Windows errors logs – aside from unexpected shutdown errors. A check disk reported no errors, and aside from the hanging the machine behaved normally.

I have reverted to a copy of the VHD taken before the compact and so far it has not hung (in 3 days).

I want to think this wasn't due to the compact process, however the timing is very suspicious and now I am very wary of using compact. However, I have not been able to find anyone else reporting a problem with it.

And yes this is a relatively unimportant production server, I know most people recommend fixed size VHD for production, but I want to minimize disk usage and don't mind a slight performance penalty.

Best Answer

I know its not going to answer your problem, but I have a few VMWare images that get compacted reasonably regularly, and I've never had the problem you describe.

I'd try again and see if you get the same errors, it's possible it was a 'glitch' (but I guess that still doesn't help if you can't trust the operation any more)

Related Solutions

What are the possible reasons why Hyper-V can’t compact a VHD

Remove the shadow copies from the guest. That will do it!

vssadmin delete shadows /all

Restarting a VM from a different VHD file (but a copy of the old one)

First of all, some basic concepts about Windows machines/domains you need to know (and may or may not already know):

Computers are security principals just like users
Names are just human-friendly references to an underlying SID
Computers authenticate to the domain on startup
Computers accounts have password too (that change every 30 days by default)

Basically, what happened when you jammed the old VHD in your machine is (I'm betting), the local password for the computer account failed to match the password the DC had for the computer account, because the password got changed sometime between the backup you did and the time you restored it. As a result, the Domain Controller wouldn't let the computer authenticate, and the error you see is a failed trust relationship.

This relies on an assumption or two, most notably that your backup and the machine that failed didn't have different SIDs, which will also break the domain trust. That commonly happens when you rename a computer or join a computer to a domain with the same name as an existing account. The newly renamed computer will try to authenticate with its new SID, but the name maps to the old SID, so when AD checks, the SIDs don't match and the authentication fails.

So either way, you basically broke authentication between your VM and the domain when you "restored" the old backup. I trust you can see why that's bad. (It's less bad if it was just the machine password, and not a different SID, which is worth mentioning.)

Why it's "bad practice" to do as you did is subjective and will get different answers (or different specific concerns) from different admins, but my answer would basically be that it's bad practice because there's a better way to do it that doesn't break domain authentication or add complexity and unknowns into the mix. (How old was the backup? What changed on the system between then and now? What's relying on those changes that could break or cause monstrously difficult to troubleshoot issues? etc.) It's also bad practice because it sounds like you don't have actual, effective backups, or a quick process to restore from [a real] backup if/when needed. That's very bad, for reasons I hope you don't need clarification on.

Having said all that, it sounds like you're relatively safe. (Assuming, of course, the old backup isn't missing a bunch of SQL data, or has an older version of something installed, or anything basic like that.) The different computer account password won't be referenced anywhere, and generally your computer's full SID isn't going be referenced by much outside of AD either, so changing it shouldn't cause problems. (But like any admin who's been around the block once or twice, I've seen stuff that would make your blood curdle and results in my qualifying what would otherwise be absolute statements.)

Hope that's helpful.

Related Topic