Open 198d opened 6 years ago
So, after trying again with a new disk image (created with qemu-img create
) and watching the hyperkit
process while running nixos-install
, I noticed that the install hung when the new disk image got to roughly the same size (in terms of number of "clusters") as the other. I went ahead and used qcow-tool create
to create a new disk image and everything worked. What is going on there?
hyperkit
and qcow-tool
share the same implementation of qcow2 and so are 100% compatible with each other.
Since the majority of our testing focuses on qcow2 files created by qcow-tool
there may still be incompatibilities with images created by qemu-img
. So for hyperkit
I recommend sticking to qcow-tool
.
Is your reproduction case easily scriptable? If so, could you file an issue against https://github.com/mirage/ocaml-qcow? Thanks!
I've been having this issue too. No automated way to reproduce, but I can reproduce easily starting with the images at http://download.cirros-cloud.net/0.4.0/. I ran the first steps on a linux box though.
$ qemu-img create -f qcow2 cirros.qcow2 3G
$ virt-resize --expand /dev/sda1 cirros-0.4.0-x86_64-disk.img cirros.qcow2
Start this image with hyperkit:
$ /Users/$USER/bin/hyperkit -A -m 1G -s 0:0,hostbridge -s 31,lpc \
-s 2:0,virtio-blk,file://$BASEDIR/cirros.qcow2,format=qcow \
-l com1,autopty=/Users/$USER/.hyperkit/crc/tty \
-f kexec,$BASEDIR/cirros-0.4.0-x86_64-kernel,$BASEDIR/cirros-0.4.0-x86_64-initramfs,"LABEL=cirros-rootfs ro console=tty0 console=ttyS0,115200n8"
Connect to its serial console:
sudo screen /dev/ttys001 115200
Login to the VM, and then run:
$ dd if=/dev/zero of=/test
The freeze described here should happen shortly after.
If in the very first step, we create the qcow2 image with lazy refcounts enabled (which qcow-tool create
enables by default) , then I no longer get the freeze:
$ qemu-img create -f qcow2 -o lazy_refcounts=on cirros.qcow2 3G
Forgot to mention, I was initially reproducing the bug on a totally different linux VM, so I suspect it can be reproduced by triggering a big enough growth of a qcow2 file without lazy refcounts
I'm evaluating Hyperkit as a platform for managing a development VM. I've built the
hyperkit
binary with the qcow2 support and have run into an issue with a possibly corrupt disk image. I was installing NixOS on the disk when I believe thenixos-install
binary ran out of memory. I forcefully killed thehyperkit
process, started it again with more memory and was going to try the install again. Unfortunately, now I can't get the VM to interact with the disk correctly: commands likefsck
andmount
just hang. Here's the output I received the last time I tried to runfsck
after booting up with the install CD (disk attached to Hyperkit withahci-hd
):qemu-img check
andqcow-tool check
both say everything is OK. I've also ranqcow-tool repair
on the image. Here's the output fromqcow-tool info
:Any advice or guidance is much appreciated.