Still happening with latest upstream kernel. It seems to involve using the -initrd option at all, with any cpio file, even a tiny one. More results posted here:
https://lists.cs.columbia.edu/pipermail/kvmarm/2014-December/012557.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1383857 Title: aarch64: virtio disks don't show up in guest (neither blk nor scsi) Status in QEMU: New Bug description: kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement) qemu from git today When I create a guest with virtio-scsi disks, they don't show up inside the guest. Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are no messages about disks, and of course nothing else works. Really long command line (generated by libvirt): HOME=/home/rjones USER=rjones LOGNAME=rjones QEMU_AUDIO_DRV=none TMPDIR=/home/rjones/d/libguestfs/tmp /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 -name guestfs- oqv29um3jp03kpjf -S -machine virt,accel=tcg,usb=off -cpu cortex-a57 -m 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid a5f1a15d-2bc7-46df-9974-1d1f643b2449 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/rjones/.config/libvirt/qemu/lib /guestfs-oqv29um3jp03kpjf.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-reboot -boot strict=on -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd -append panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000 no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color -device virtio-scsi-device,id=scsi0 -device virtio-serial-device,id=virtio- serial0 -usb -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/scratch.1,if=none,id =drive-scsi0-0-0-0,format=raw,cache=unsafe -device scsi- hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive- scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/overlay2,if=none,id =drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi- hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive- scsi0-0-1-0,id=scsi0-0-1-0 -serial unix:/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/console.sock -chardev socket,id=charchannel0,path=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/guestfsd.sock -device virtserialport,bus=virtio- serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 -msg timestamp=on There are no kernel messages about the disks, they just are not seen. Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a qemu bug, but I've no idea where to report those. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1383857/+subscriptions
