Closed philclifford closed 2 months ago
flexiondotorg
commented
2 months ago This regress was introduced via:
In an effort to fix https://github.com/quickemu-project/quickemu/pull/848
Thanks @philclifford for this comment:
Here's some more activity for the disk health check:
flexiondotorg
commented
2 months ago The disk health check is a feature that is broken by design: https://github.com/quickemu-project/quickemu/pull/848
qemu-img check will always fail because it can not get a write lockquickemu can start VMs in the background (--display spice, for example), and the health check then breaks all further use of quickemu that operates on that running VM.
TuxVinyards
commented
2 months ago This is a general test that I use for my disk maintenance routines to avoid Qemu lock problems.
# use pgrep with -x exact match to avoid 'kvm-cleanup' processes being detected
[[ $(pgrep -x kvm) ]] && printColor "\n\n VIRTUAL MACHINE ACTIVITY has been DETECTED \n" Thinking aloud a bit here, as just got back from a short break and I haven't tested. But would adding this as a conditional to the disk health checker work?
Edit
The disk health check is a feature that is broken by design: https://github.com/quickemu-project/quickemu/pull/848
That was fixed in #993 with the addition of an if exist .... So add another, if no kvm ...
flexiondotorg
commented
2 months ago The implementations, as submitted to quickemu in #848 and #993, are both broken. Here is a working implementation: https://github.com/quickemu-project/quickemu/pull/1199/commits/5ec5c51e22d6931dc5b2c6864ec76b2e3f52629f
Expected behavior
--monitor-cmd works as documented
Actual behavior
--monitor-cmd (and presumably other options that work with a running VM) break due to invocation of qemu-img to check the disk, which of course fails as it is in use.