1 0 0 98 0 1| 0 0 | 66B 354B| 0 0 | 30 11
1 1 0 98 0 0| 0 0 | 66B 354B| 0 0 | 29 11
From that point onwards, nothing will happen.
The host has disk IO to spare... So what is it waiting for??
Moved to an AMD64 host. No effect.
Disabled swap before running the test. No effect.
Moved the guest to a fully up-to-date FC12 server
(2.6.31.6-145.fc12.x86_64), no effect.
I have narrowed it down to the guest's filesystem used for backing the
disk image which is loop mounted: although it was not completely full
(and had enough inodes), freeing some space on it prevents the system
from misbehaving.
FYI: the disk image was clean and was fscked before each test. kvm had
been updated to 0.12.3
The weird thing is that the same filesystem works fine (no system hang)
if used directly from the host, it is only misbehaving via kvm...
So I am not dismissing the possibility that kvm may be at least partly
to blame, or that it is exposing a filesystem bug (race?) not normally
encountered.
(I have backed up the full 32GB virtual disk in case someone suggests
further investigation)
Cheers
Antoine
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
