Recently a guest VM goes to Guru Meditation state with a critical error instead of starting normally

[milverton]

I am a newcomer to this forum. My issue is that a Linux-hosted Windows-7 guest VM on an HP Envy x360 with AMD Ryzen 4000 series processor does not complete its startup. Instead it is now going into Guru Meditation state with a critical error. It has previously run with no problems.

If anyone has an insight on this do please refer to the log file attached. I am now using the Linux distribution Ubuntu 20.04.4 LTS with Linux kernel 5.13.0-39-generic.

I don't know if this gives any clues, but if you ask me what is the latest significant change I have noticed with the computer it is that very recently the S3 sleep state has begun working beautifully in Ubuntu - something I have looked forward to for a long time!

Any suggestions as to how I can avoid the critical error would be very much appreciated. Thank you, thank you.

[mpack]

Did the VM previously work on this host PC? If yes then it looks like corruption of the Win7 hard disk, and fixing that would require a VM backup or perhaps a Win7 boot repair DVD.

I see that you're also sailing pretty close to the wind with your RAM: 4.5GB available, 4GB allocated + 128MB graphics RAM. I would reduce the allocation to 3GB or even 2GB.

The VM could use a second CPU core too. After all the host has 8 available.

[milverton]

Thank you mpack. Yes the VM did work previously on this host PC.

Taking easy steps first, I tried the RAM and core count changes you suggested, cautiously in stages, but they didn't affect things so I reversed them for now.

It seems new VMs I create work fine, but old ones do not. Your suggestion of a hard disk corruption was daunting; I've been trying to pursue it. Late yesterday it dawned on me I've completely missed a major point of understanding regarding dynamic disks for guest VMs. I have Ubuntu partition backups from two dates. The backups were made with Diskgenius. When I attempt to recover any of the vdi files from the partition backups, the copy process just goes on and on and on, way past the completion point I would have expected. So I need to take time out from this topic to study up on this and see if there is any hope for recovering usable vdi files from either of the partition backups. I will search for topics that might help me with that. My goal has now changed to recovery.

Staying on-topic though, I'm convinced the Linux kernel S3 sleep issue with the HP Envy x360 AMD Ryzen 7 4700U Processor is a suspect here for disk corruption. From time to time it necessitated shutting down the machine improperly. But now that it has been solved with Ubuntu 20.04.4 LTS and Linux kernel 5.13.0-39-generic, I have renewed interest in being able to do real creative work with this VM.

Thank you again.

[mpack]

I can't think of any reason why the fact that a dynamic VDI is used should have any relevance to your backup scheme, whether inside the guest or on the host.

A dynamic VDI is just a file on the host. Not in any way special nor especially complex compared to other host files.

[milverton]

mpack, I totally agree with your thinking about there being no consequential differences in vdi files which occur depending on whether the virtual hard disks are fixed or dynamic. I've abandoned the study of that issue for now, but it might still hold a clue. My goal is still recovery, if possible.

In the meantime I've stumbled on the one thing - a Diskgenius setting - that affects whether the vdi files survive a partition backup and restore. That is not to say, though, that I understand why: that's something you and others might have insight on. And, further I haven't tested to see if it makes a difference whether the vdi files are fixed or dynamic: the ones I've created, used, and included in backups so far have all been dynamic.

Diskgenius has 2 rows of "Settings" selectable at the start of a "partition image backup" operation. Row 1 has 3 radio buttons to determine what exactly is backed up; the labels are: "All Sectors"; "Data Sectors Only"; and the default, which is "All Files". Row 2 has 4 radio buttons to determine the Compression Mode; the labels are: "No Compress"; "Fast"; the default, which is "Normal"; and "High Quality". By changing (only) the Row 1 setting to "All Sectors", the vdi files survive the backup. In order to use that setting I needed to enter a license key; but it turns out I had one from another occasion when I needed one. (That was for "lost" file recovery in a real PC hard drive failure scenario; in which the outcome was most successful.) In any case, entering the license key allowed the "All Sectors" backup to proceed, which went flawlessly; and when I deleted the partition, then made sure it still showed in WIndows Disk Manager, and then restored the partitition from the image backup, that process also went flawlessly. (I return to that word later on in this post.) Afterwards, I had no trouble running the latest Windows 7 VM, created shortly before undertaking that test.

That is a breakthough, and a major one, but the understanding is missing.

So it turns out that a vdi file is of a kind which can present a problem; and does predictably present a problem when the default "All Files" setting is used - in the backup operation rather than the restore operation - with Diskgenius.

Diskgenius gives the following descriptions to the two settings I've used:

For the successful setting, "All Sectors", the description is...

• Backup all sectors of source partition to image file, no matter the sectors contain valid data or not.
  Many invalid sectors may be backupped, so it is only used in some special case.
  The backup speed may be very slow.
  This mode requires that the capacity of target partition should not [be] less than the source one while restoring from image file.

For the "destructive" setting (seemingly just for vdi files) the description is...

• Backup all files and other valid sectors in soure partitions.
  While restoring, the file data on target partition will be rearranged.
  This mode only requires that the capacity of target partition exceed the used size of source partition while restoring.
  The backkup speed is fast.

I do still have the earlier unaltered Linux full partition backups, but they were made with the "All Files" setting in Diskgenius. Their parameters suggest all the sectors were noted somehow; in other words, they do say that their size is the right size to match the subject partition.

I'd like to pose the question: knowing the process used which led to this issue, would it still be possible, somehow, to extract error-free vdi files from those earlier backups?

That little sentence in the instructions for the default setting - "While restoring, the file data on target partition will be rearranged." - could that be the clue?

Speaking of clues, here's something else I noticed. I used the word flawlessly for the successful backup and restore. But during restoring the parftition from image backups done with the default setting of "All Files", the process did not go flawlessly: there were a number of errors reported. They didn't stop the proces, though. They all had exactly the same wording, namely

• "Write disk error."Note: Error has been omitted. The restored data will have errors.

This happened in batches at different stages during the backup The count of those exact errors was about 30; or, in two runs, about 120.

The now-adapted main question remains: is there a chance that, somehow, error-free vdi files could be recovered from the earlier backups?

(Can't help wondering if a slightly different topic heading should be started, with this slight breakthrough...)

[scottgus1]

I'm not familiar with DiskGenius. But there are fundamentally only two reliable methods to back up a VM:

1. Shut down the VM completely, then make a standard file copy of all of the VM's files on the host.

2. Run 3rd-party backup software inside the running VM that's fully compatible with the services running in the VM, and save the backup images outside the VM through a network to a real shared folder on other media.

If your backup process was working in the host OS on a running VM, then the backups are corrupted. A running OS must know it's being backed up and prepare itself accordingly. Without the preparation, the data won't be ready for backup.

[milverton]

Thank you scottgus1, for your insight.

My backkup method was not either of the two methods you list. Perhaps that's where the problem lies, indeed. But the backups I'm talking about are not VM backups; they are a step further out: Linux partition backups. The Linux partition is next in line after the Windows (C:) partition on the real hard drive, but naturally enough it doesn't have a Windows drive letter, being labeled in a generic way instead. When Windows sees the Linux partition in Disk Manager it doesn't say anything meaningful about it, other than it's healthy, I think. But Diskgenius is ok with it.

Not only was the VM shut down, but VIrtualbox (hosted by Linux/Ubuntu) was shut down, and Linux/Ubuntu was shut down, when the backups were made. Diskgenius runs in Windows, and the backups were done with Diskgenius running in Windows 10.

(As mentioned the machine is running an AMD processor (details earlier), which has presented the Linux kernel team with a long path to overcome, related to S3 sleep. Recently that enormous setback was indeed overcome.)

This scenario for backing up the Linux Ubuntu partition is common to all the backups I've made of Linux. It's interesting to me now, to learn from you that it's possible to back up a running VM, but it's something I've never attempted. I'm familiar with some of the terms you're using, though, through years of experience with twice-daily automated backups of Windows PCs using Macrium Reflect, done with the PC running.

A strange thing is, there's nothing in the backups to suggest they are corrupted. Diskgenius can compose a file list of all the contents of the image backups it has made of the Linux partition, using the command "Extract files from partition image", and also other information which appears to be correct. But when it comes to the vdi files themselves they are presented as a single file. And it seems to be only those files which are corrupted somehow if the "All Files" setting in Diskgenius is used when making the backups. I can see the dvi files readily just like all the other files in the "loaded partition image" which Diskgenius can generate. But I can't drill any further into the dvi files, regardless of the setting.

I'm leaving open the possibility that it is related to the vdi files being dynamic rather than fixed, for now. And either way, I am more relaxed about the situation now, knowing that changing the one Diskgenius setting gets me over the problem, even though it is still not understood.

For now I'm holding out hope that there is valid data for the vdi files in the backups made using the wrong setting, and that the thing that's needed is a way of putting it back together correctly, or something like that. I don't suspect, for example, that it's a defective real-media issue.

I am certainly interested in the more focused backup methods you list. I will do homework on them. I've used the Virtualbox "clone" capability with a VM, but not while any VM is actually running. And I don't think I've mastered it. Is that what you're referring to by "make a standard copy" of any given VM?

I'm sorry if this is a bit longwinded!

[mpack]

I've stumbled on the one thing - a Diskgenius setting - that affects whether the vdi files survive a partition backup and restore.

I have no idea what that means. The only similar setting I've come across in the past is when the backup tool has an option to skip large files. In that case it has nothing to do with the VDI being dynamic, it's purely a file size issue. And it would mean that the VMs are not backed up. Rather, the control and log files will be backed up, but obviously they are useless without the disk contents.

I don't really know what "Data sectors only" might mean either, but apparantly it doesn't include the partitions where you keep your VMs.

[milverton]

Thank you, mpack. The possibility of a file-size-based skipping trigger is a valuable insight. It does seem to be compatible with all the symptoms I've described from the beginning of this topic. And it would mean there is no hope for data recovery of the kind I mentioned in my response to scottgus1.

I suppose there could be some other basis on which the software is making decisions. For example, the adjective "valid" is used with the noun "sector". What could that be about? After all, these vdi files aren't really that large in today's world. Could it be that, being a Windows-based product which says it's capable of working with Linux files, Diskgenius really doesn't know well enough what it's doing when it's confronted with a Linux file system?

The view I take of this is that if the software wants to make sophisticated decisions it should point out what it's doing by means of a confirmation step before starting a backup; rather than, as now, only advising of errors during a restore operation.

The description for the as-yet untried setting "Data Sectors Only", which I omitted previously is...

• Backup all valid sectors to image file according to the layout of the file system. The invalid sectors will not be backupped.
  This is the fastest mode because only valid sectors will be backkupped.
  This mode requires that the capacity of the target partition should not [be] less than the source one.

[milverton]

One other thought:

How could Diskgenius make an informed decision about whether the sectors used by any given VDI file it encounters, taking into account the range of OSes possible, are "valid"?

[scottgus1]

I suspect that a backup program can read the file table to see what blocks on the source drive are still considered used by the OS being backed up. (This along the lines that a file that is deleted is not actually erased over on the blocks of the drive that contained that file. Only the file table is marked that those blocks are now free for writing. So the backup software wouldn't have to back up those blocks.)

It sounds like you have a dual-boot Windows/Linux host, and the Linux OS has a Windows VM in the Linux partition. You're using DiskGenius to back up the Linux Partition, and the suspicion is that the VM's vdi is getting corrupted in the backup process.

Regarding the guru-meditating Windows VM, please double check that KVM is not running on the Linux OS.

Is the guru-meditating Windows VM in the first post restored from your DiskGenius backups? Or is it the original VM?

[milverton]

It sounds like you have a dual-boot Windows/Linux host, and the Linux OS has a Windows VM in the Linux partition. You're using DiskGenius to back up the Linux Partition, and the suspicion is that the VM's vdi is getting corrupted in the backup process.

Correct... though I think - and should probably verify through another test - that the 32-bit Windows VM (for XP) (including its vdi file), which I created for an unrelated test, did survive.

Regarding the guru-meditating Windows VM, please double check that KVM is not running on the Linux OS.

If I search in the Ubuntu Activities window for KVM I get "No Results". If I run the terminal command sudo kvm-ok in the Linux OS I get the response sudo: kvm-ok: command not found. That's without any preparation steps. Is that answer sufficient? In order to have KVM running wouldn't I need to be aware that I had installed it? (I haven't - at least, not knowingly.) Or could it get installed some other way.?

Is the guru-meditating Windows VM in the first post restored from your DiskGenius backups? Or is it the original VM?

Yes (restored, not original)...

...and, timewise, that was all before it dawned on me that the backing up and restoring could - far from being protection against data loss - be the cause of it.

(I never had that experience in all the years I used Macrium Reflect, for example; and my previous experience with Diskgenius (which involved only Windows files) was itself free of any corruption issues.)

[scottgus1]

In order to have KVM running wouldn't I need to be aware that I had installed it?

There's been some Linux host folks who haven't.

I'm no Linux expert, I just heard about KVM up-ending Virtualbox from forum guru 'fth0', so I'm not certain how to test for its presence. The log did not show the telltale KVM indicators, but the VM meditating so early in the startup seemed like a serious issue might be in play.

Of course, a corrupted vdi might also be such a serious issue...

backing up and restoring could - far from being protection against data loss - be the cause of it.

Very possible. A restore test should be run to check the backup. I use Macrium Reflect, too. I always run a verify after the image is done. Any file copy done in the host OS has a file-compare to check the copy's integrity. I have restored from a Macrium image, too.

Macrium is supposed to back up Linux partitions as long as the Linux OS isn't running.

[fth0]

I just heard about KVM up-ending Virtualbox from forum guru 'fth0', so I'm not certain how to test for its presence.

Here's a real-life example:

$ lsmod | grep kvm
kvm_intel             282624  0
kvm                   663552  1 kvm_intel

$ qemu-system-x86_64 -enable-kvm &

$ lsmod | grep kvm
kvm_intel             282624  3
kvm                   663552  1 kvm_intel

$ ps -elfH | grep kvm
2 S fth0        3992    2685 19  80   0 - 152806 poll_s 23:41 pts/1   00:00:05       qemu-system-x86_64 -enable-kvm

The lsmod command displays the current number of users of a Linux kernel module. In the example above, the kvm module is used by the kvm_intel module, and the kvm_intel module is initially not in use. After starting a QEMU/KVM VM in the background ('&'), the kvm_intel module is in use, and the ps command gives a hint what to look for.

[milverton]

Not fully understanding at this point, but hanging in with you!

After starting a QEMU/KVM VM in the background ('&'), the kvm_intel module is in use,

Is this something you did by starting a particular VM? or how did this happen?

When I use the terminal window as you suggest, I get this (in response to just the first command):

Code: Select all

$ lsmod | grep kvm
kvm_amd               118784  0
kvm                   864256  1 kvm_amd
ccp                    98304  1 kvm_amd

I need more guidance to go further, but if the responses in the terminal window get lengthy do you want me to edit (prune) them, to focus on something in particular?
(I can do that in Notepad++ before posting)