HCHTech
Well-Known Member
- Reaction score
- 4,178
- Location
- Pittsburgh, PA - USA
I was casually looking at some of my servers today, and came across a nice fail to start the new year.
I'm titling this: Yet another episode of Mark's 'Learn Hyper V by screwing things up'. Ha. Not so bad, but as with most of these, I haven't done it before, hence this post.
This installation is a single Hyper V host, with 2 VMs, a DC and an Application server. Server 2016 Standard.
Back in September, I was trying out a new backup software on the host, and ended up with a recovery checkpoint on the App Server that didn't delete correctly when the backup was interrupted by a power outage or maybe I misconfigured the target - something like that. Everything came back up ok, but that checkpoint remained. I tried to merge it at the time (here is one overview of the process I attempted), but got the apparently predictable "Virtual Machine failed to generate the VHD tree" error, with the details noting "Catastrophic Failure 0X8000FFFF". I googled this error and saw that it would likely require some manual work, so since everything was working, I put that on my to-do list for the next maintenance interval.
Well, life intervened or something like that and I never got around to fixing this. So here we are 3 months later. Some powershell commands confirm that the problem checkpoint is definitely a recovery checkpoint, and just like before, it won't merge with the standard PS commands, and there is no delete option in the GUI. - turns out problems don't just fix themselves if ignored!
Today's researching tells me that exporting the VM will likely force a merge, and that exported VM can then be imported to the host to replace the existing VM to fix the problem, possibly requiring some reconfiguration. Here is one brief overview, there are lots of others.
So...Do you concur this is the best approach? I note that the avhdx file still has the September date, so it hasn't been changed since the date of the event. There are no other checkpoints as I did heed the advice of not enabling checkpoints in a production environment.
Also, this VM has two VHDs connected to it, a 320GB Dynamic (104GB used) for the OS and a 900GB Fixed (600GB used) for the data. That means that the export will contain the machine files (about 100GB) as well as the two VHDs (I think that would total 104 + 900GB = 1004GB), and of course the checkpoint (9GB) for a grand total of 1113GB needed for the export - far more than is available at this point. Would it save time and space by disconnecting the data drive from the VM prior to the export? I'll need to connect a drive to provide space for this project in any event, but if I can do something to speed this along, it's worth some planning.
I'm titling this: Yet another episode of Mark's 'Learn Hyper V by screwing things up'. Ha. Not so bad, but as with most of these, I haven't done it before, hence this post.
This installation is a single Hyper V host, with 2 VMs, a DC and an Application server. Server 2016 Standard.
Back in September, I was trying out a new backup software on the host, and ended up with a recovery checkpoint on the App Server that didn't delete correctly when the backup was interrupted by a power outage or maybe I misconfigured the target - something like that. Everything came back up ok, but that checkpoint remained. I tried to merge it at the time (here is one overview of the process I attempted), but got the apparently predictable "Virtual Machine failed to generate the VHD tree" error, with the details noting "Catastrophic Failure 0X8000FFFF". I googled this error and saw that it would likely require some manual work, so since everything was working, I put that on my to-do list for the next maintenance interval.
Well, life intervened or something like that and I never got around to fixing this. So here we are 3 months later. Some powershell commands confirm that the problem checkpoint is definitely a recovery checkpoint, and just like before, it won't merge with the standard PS commands, and there is no delete option in the GUI. - turns out problems don't just fix themselves if ignored!
Today's researching tells me that exporting the VM will likely force a merge, and that exported VM can then be imported to the host to replace the existing VM to fix the problem, possibly requiring some reconfiguration. Here is one brief overview, there are lots of others.
So...Do you concur this is the best approach? I note that the avhdx file still has the September date, so it hasn't been changed since the date of the event. There are no other checkpoints as I did heed the advice of not enabling checkpoints in a production environment.
Also, this VM has two VHDs connected to it, a 320GB Dynamic (104GB used) for the OS and a 900GB Fixed (600GB used) for the data. That means that the export will contain the machine files (about 100GB) as well as the two VHDs (I think that would total 104 + 900GB = 1004GB), and of course the checkpoint (9GB) for a grand total of 1113GB needed for the export - far more than is available at this point. Would it save time and space by disconnecting the data drive from the VM prior to the export? I'll need to connect a drive to provide space for this project in any event, but if I can do something to speed this along, it's worth some planning.
