10.11.2010 20:14, Michael Tokarev wrote:
> Oluf Lorenzen wrote:
>> Here you are:
>> /usr/bin/qemu-kvm -S -M pc-0.12 -enable-kvm -m 100 \
...
>> -drive
>> file=/var/lib/libvirt/images/squeeze-test.img,if=none,id=drive-virtio-disk0,format=raw
>> \
>> -device
>> virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \
I tested with 3 versions of libvirt - from squeeze, sid and
experimental (versions 0.8.3-3, 0.8.3-4 and 0.8.4-1). All
3 uses additional argument for the first -drive parameter,
which is "boot=on":
...
-rtc base=utc -boot c \
-drive file=/stage/w7.raw,if=none,id=drive-virtio-disk0,boot=on,format=raw \
^^^^^^^
-device
virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0
...
And in all cases the vm works just fine.
As far as qemu-kvm is concerned, it works as it should, according
to the implementation: in order to boot from a virtio disk, 0.12
needs "boot=on" argument for that disk, in case there are only
virtio disks available (without boot=on) and -boot c given, it
will display the message you encountered, telling you it can't
read from a disk - because there's no disks visible to the BIOS.
0.13 recognizes virtio disks, but this is because it uses different
bios and slightly different "controller". It was the same with
PC too: some SCSI controllers requires custom boot code (which
is provided by "boot=on") in order to become bootable, and by
default BIOS were able to boot only from IDE disks.
So we've two questions:
1) what is your /usr/bin/qemu-kvm - it is not from qemu-kvm
package for sure.
2) what version of libvirt you're using and why it is not
adding that "boot=on" parameter.
I'll close this bug in a few days unless you come with some
information about this.
Thanks!
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
