Antoine Martin wrote: > [snip] >> >> So there is something else at play. And just for the record: >> 1) kvm-88 works fine *with the exact same setup* >> 2) I've tried running as root >> 3) The raw disk mounts fine from the host. >> So I *know* the problem is with kvm. I wouldn't post to the list >> without triple checking that. >> >> I have also just tested with another raw partition which is much >> smaller (1GB) and the same thing still occurs: kvm-88 works and >> qemu-kvm-0.12.3 does not. >> So I think that it is fair to assume that this new problem is >> unrelated to the partition size. > I have narrowed it down to the "io-thread" option: > * rebuilding older versions of qemu without "--enable-io-thread" causes > the bug (guest cannot open raw partition) > * qemu-kvm-0.12.3 cannot be built with "--enable-io-thread" over here: > LINK x86_64-softmmu/qemu-system-x86_64 > kvm-all.o: In function `qemu_mutex_lock_iothread': > /usr/src/KVM/qemu-kvm-0.12.3/qemu-kvm.c:2532: multiple definition of > `qemu_mutex_lock_iothread' > vl.o:/usr/src/KVM/qemu-kvm-0.12.3/vl.c:3772: first defined here > [..] > Which I have reported as part of another unsolved issue here: > http://www.mail-archive.com/kvm@xxxxxxxxxxxxxxx/msg27663.html > > Why not using the io-thread would prevent qemu from opening the raw > partition is beyond me. Ok, this is in fact different problem, not the one I referred you initially (which was in fact good too, because apparently Christoph solved that bug for me and for other Debian users, thank you!). In your case, recalling your initial email: > With qemu-kvm-0.12.3: > ./qemu-system-x86_64 [..] -drive file=/dev/sdc9,if=virtio,cache=none [..] > [ 1.882843] vdc: > [ 2.365154] udev: starting version 146 > [ 2.693768] end_request: I/O error, dev vdc, sector 126 > [ 2.693772] Buffer I/O error on device vdc, logical block 126 > [ 2.693775] Buffer I/O error on device vdc, logical block 127 > [ 2.693777] Buffer I/O error on device vdc, logical block 128 ... the problem happens right at startup, it can't read _anything_ at all from the disk. In my case, the problem is intermittent and happens under high load only, hence the big difference. But anyway, this is something which should be easy to find out. Run kvm under `strace -f' and see how it opens the device, or find out with lsof what filedescriptor corresponds to the file in question (in running kvm instance) and see flags in /proc/$kvm_pid/fdinfo/$fdnum. I guess it can't open the image in read-write mode somehow. By the way, iothread doesn't really work in kvm, as far as I can see. Thanks. /mjt -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
