On Mon, Dec 12, 2011 at 3:19 PM, takizo <paul...@takizo.com> wrote: > > On Dec 12, 2011, at 11:08 PM, Stefan Hajnoczi wrote: > >> On Mon, Dec 12, 2011 at 2:50 PM, takizo <paul...@takizo.com> wrote: >>> >>> On Dec 12, 2011, at 6:56 PM, Stefan Hajnoczi wrote: >>> >>>> On Sun, Dec 11, 2011 at 4:40 PM, takizo <paul...@takizo.com> wrote: >>>>> LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none >>>>> /usr/libexec/qemu-kvm -S -M rhel6.1.0 -enable-kvm -m 4096 -smp >>>>> 1,sockets=1,cores=1,threads=1 -name database -uuid >>>>> f3e9f320-7826-7e50-94bb-1833f7fd9dfb -nodefconfig -nodefaults -chardev >>>>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/database.monitor,server,nowait >>>>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc >>>>> -no-reboot -drive >>>>> file=/opt/cibai/database,if=none,id=drive-ide0-0-0,format=raw,cache=none,aio=threads >>>>> -device >>>>> ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 >>>>> -drive >>>>> file=/opt/ISO-Download/FreeBSD-8.2-RELEASE-amd64-disc1.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,aio=threads >>>>> -device >>>>> ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 >>>>> -netdev tap,fd=22,id=hostnet0 -device >>>>> e1000,netdev=hostnet0,id=net0,mac=52:54:00:77:a5:a6,bus=pci.0,addr=0x3 >>>>> -chardev pty,id=charserial0 -device >>>>> isa-serial,chardev=charserial0,id=serial0 -usb -vnc 127.0.0.1:2,password >>>>> -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 >>>>> char device redirected to /dev/pts/6 >>>>> Using CPU model "cpu64-rhel6" >>>>> >>>>> block I/O error in device 'drive-ide0-0-0': Invalid argument (22) >>>> >>>> Is /opt/cibai/database on a special filesystem or exotic storage setup? >>>> >>>> Please check dmesg on the host for any kernel messages regarding I/O >>>> errors. >>>> >>>> Please try reading the file on the host to check whether the I/O error >>>> is happening on the host and not related to KVM: >>>> >>>> $ dd if=/opt/cibai/database of=/dev/null iflag=direct >>>> >>>> Stefan >>> >>> Hi Stefan, >>> >>> When I quit the installation, further see the error messages >>> >>> ide_dma_cancel: aiocb still pendingide_dma_cancel: BM_STATUS_DMAING still >>> pendingide_dma_cancel: aiocb still pendingide_dma_cancel: BM_STATUS_DMAING >>> still pendingide_dma_cancel: aiocb still pendingide_dma_cancel: >>> BM_STATUS_DMAING still pendingide_dma_cancel: aiocb still >>> pendingide_dma_cancel: BM_STATUS_DMAING still pendingide_dma_cancel: aiocb >>> still pendingide_dma_cancel: BM_STATUS_DMAING still pendingide_dma_cancel: >>> aiocb still pendingide_dma_cancel: BM_STATUS_DMAING still pending2011-12-12 >>> 22:47:51.427: shutting down >>> > > Hi Stefan > >> Okay, so if I understand correctly you have CentOS 6.1 host running >> FreeBSD and CentOS guest installs to emulated IDE drives. You're >> getting failed I/O requests with EINVAL (22). You have verified that >> dd if=/opt/vm/database.img of=/dev/null iflag=direct reads the image >> file without errors. > > That is right, both also emulated on IDE drive > >> >> Can you please try the CentOS guest install with a virtio-blk drive >> instead of IDE? This should show whether this problem is related to >> IDE or a general issue in how QEMU accesses the host file. > > Took your advice installed Centos on VirtIO drive and it's ok. > > Does it means it's IDE problem on the OS itself?
The physical drive in your machine is probably fine. QEMU emulates an IDE controller and disks for the guest. It looks like there is a bug in the IDE emulation code inside QEMU which leads to these errors. In general virtio-blk is the recommended storage interface because it delivers better performance. I'm not up-to-speed on how stable the FreeBSD virtio drivers are but I think they are available if you search. > 2011-12-12 23:15:06.759: starting up > LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none > /usr/libexec/qemu-kvm -S -M rhel6.1.0 -enable-kvm -m 1024 -smp > 1,sockets=1,cores=1,threads=1 -name centos -uuid > 0752c74e-1d51-d529-f66f-8df9a28670ed -nodefconfig -nodefaults -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/centos.monitor,server,nowait > -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-reboot > -drive > file=/opt/vm/centos.img,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=threads > -device > virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 > -drive > file=/opt/ISO-Download/CentOS-6.0-x86_64-minimal.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,aio=threads > -device > ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 > -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=26 -device > virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:10:bc:5d,bus=pci.0,addr=0x3 > -chardev pty,id=charserial0 -device > isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 > -vnc 127.0.0.1:3,password -vga cirrus -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 > char device redirected to /dev/pts/9 > Using CPU model "cpu64-rhel6" At this stage of debugging I would try enabling SystemTap probes in QEMU related to block I/O. This produces a detailed log of what is happening inside QEMU. strace -f -p $PID_OF_QEMU might also reveal how the I/O is failing. Finally, gdb could be of use. I'm not sure how familiar or easy it is for you to try these so let's see if Kevin or someone else has other ideas before getting into the nitty-gritty of finding out why you get EINVAL (22). Stefan
