Hello,
I have encountered a problem with the bootindex parameter for a KVM guest that has two virtio-blk disks. Although I set bootindex=1 for the second disk, the VM chooses rather randomly the disk it boots from.
host CPU: AMD Phenom II X4 955 Processor host OS (first): x86_64 debian-squeeze (kernel 2.6.38 amd64) host OS (later): x86_64 debian-squeeze (kernel 3.0 amd64) guest OS (both disks): e.g. x86_64 debian-squeeze (2.6.32 amd64)
This is how I invoke qemu (most of the times tested with Debian squeeze images):
# /usr/bin/qemu-system-x86_64 \ -m 256 \ -name test4221 \ -uuid f5dc124f-cbf4-6220-8b6b-15c0662be798 \ -nodefconfig \ -nodefaults \ -drive file=/opt/dev/4223,if=none,id=mydrive0,format=raw \ -device virtio-blk-pci,bus=pci.0,addr=0x7,drive=mydrive0,id=mydisk0,bootindex=2 \ -drive file=/opt/dev/4256,if=none,id=mydrive1,format=raw \ -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=mydrive1,id=mydisk1,bootindex=1 \ -vga cirrus
(both tested, with and without bootindex=2 for the first disk)
When both disks contain different OS images (Debian vs. Windows), everything is fine. But when I try two disks with the same OS on them, (no matter whether both are Debian or both are Windows), then when
first starting the VM (by a call to qemu-system-x86_64) or simply rebooting the VM again and again,
the disk that is booted from seems to be chosen rather randomly.
I had qemu-kvm 0.14.0 and seabios 0.6.2 on the host when the problem was first encountered. Then I replaced seabios with the current version compiled from the git repository. Finally I removed qemu-kvm and seabios completely and did a "make install" with qemu-kvm 0.15 from the git repository.
# qemu-system-x86_64 -version QEMU emulator version 0.15.50 (qemu-kvm-devel), Copyright (c) \ 2003-2008 Fabrice Bellard
When I was using seabios post-0.6.2 from the git repo, I set its debug level to 5 and compared the debug output for the good and bad cases and found no difference.
Am I missing something or did I stumble over a bug?
Any hint would be welcome,
Elmar
On Tue, Aug 16, 2011 at 11:35:17AM +0200, Elmar Gerdes wrote:
Hello,
I have encountered a problem with the bootindex parameter for a KVM guest that has two virtio-blk disks. Although I set bootindex=1 for the second disk, the VM chooses rather randomly the disk it boots from.
[...]
When I was using seabios post-0.6.2 from the git repo, I set its debug level to 5 and compared the debug output for the good and bad cases and found no difference.
Can you post one of the debug logs?
-Kevin
On 16/08/11 14:45, Kevin O'Connor wrote:
On Tue, Aug 16, 2011 at 11:35:17AM +0200, Elmar Gerdes wrote:
I have encountered a problem with the bootindex parameter for a KVM guest that has two virtio-blk disks. Although I set bootindex=1 for the second disk, the VM chooses rather randomly the disk it boots from.
[...]
When I was using seabios post-0.6.2 from the git repo, I set its debug level to 5 and compared the debug output for the good and bad cases and found no difference.
Can you post one of the debug logs?
Of course. The only diffs I see after some further tests is in the number of lines complaining about int09h_handler() and the CPU Mhz line.
Elmar
On Tue, Aug 16, 2011 at 03:19:27PM +0200, Elmar Gerdes wrote:
On 16/08/11 14:45, Kevin O'Connor wrote:
On Tue, Aug 16, 2011 at 11:35:17AM +0200, Elmar Gerdes wrote:
I have encountered a problem with the bootindex parameter for a KVM guest that has two virtio-blk disks. Although I set bootindex=1 for the second disk, the VM chooses rather randomly the disk it boots from.
[...]
When I was using seabios post-0.6.2 from the git repo, I set its debug level to 5 and compared the debug output for the good and bad cases and found no difference.
Can you post one of the debug logs?
Of course. The only diffs I see after some further tests is in the number of lines complaining about int09h_handler() and the CPU Mhz line.
The key lines are:
[...]
Copying romfile 'bootorder' (len 54) boot order: 1: /pci@i0cf8/scsi@4/disk@0,0 2: /pci@i0cf8/scsi@7/disk@0,0
[...]
virtio-blk 0:4 blksize=512 sectors=14679654 Searching bootorder for: /pci@i0cf8/*@4 Registering bootable: Virtio disk PCI:0:4 (type:2 prio:1 data:fd8c0)
[...]
virtio-blk 0:7 blksize=512 sectors=10485350 Searching bootorder for: /pci@i0cf8/*@7 Registering bootable: Virtio disk PCI:0:7 (type:2 prio:2 data:fd890)
[...]
Registering bootable: Legacy option rom (type:129 prio:9999 data:c9000003) Mapping hd drive 0x000fd8c0 to 0 drive 0x000fd8c0: PCHS=14563/16/63 translation=lba LCHS=913/255/63 s=14679654 Mapping hd drive 0x000fd890 to 1 drive 0x000fd890: PCHS=10402/16/63 translation=lba LCHS=652/255/63 s=10485350
The virtio device at address 4 was requested first, and the virtio device at address 7 was requested to be second. SeaBIOS did do that - the virtio device at 4 (fd8c0) was mapped to the C drive. From your previous email, it looks like this is what was intended from the qemu command line.
So, something else must be going on here - it looks to me like SeaBIOS is doing the right thing. Maybe something in the bootloader on the drives is confused? Also, note that the bootorder only specifies which device SeaBIOS will attempt to boot off - it does nothing to order how the OS will see the drives.
-Kevin
-
Elmar Gerdes -
Kevin O'Connor