Bug 1420869
Summary: | no bootable device found with more than one virtio-scsi disc | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Stefan Wandl <swandl> | ||||||||
Component: | seabios | Assignee: | Paolo Bonzini <pbonzini> | ||||||||
Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 7.0 | CC: | amureini, bugs, chayang, coli, juzhang, knoel, michal.skrivanek, michen, mlipchuk, pbonzini, redhat-bugzilla, robert.scheck, swandl, tjelinek, tnisan, virt-maint, xfu, xuwei | ||||||||
Target Milestone: | pre-dev-freeze | Keywords: | Reopened | ||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | |||||||||||
: | 1432847 (view as bug list) | Environment: | |||||||||
Last Closed: | 2017-11-17 14:03:03 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | 1020622 | ||||||||||
Bug Blocks: | 1432847 | ||||||||||
Attachments: |
|
Description
Stefan Wandl
2017-02-09 17:05:36 UTC
can you please provide engine and vdsm logs? Created attachment 1249002 [details]
VDSM and Engine Logs
teh related machine is named test2, i have only added those vdsm logs which are somehow related to the test2 vm. The vm was created at 2017-02-09 11:31
Hi Stefan, I was not able to simulate this nor I have found anything suspicious in the logs, so I need to ask some questions: - please make sure that in the boot options of the VM the Hard Disk is the first (edit vm -> boot options) - please make sure in Resource Allocation tab the "VirtIO-SCSI Enabled" checkbox is checked - if you have both, please try to run the VM as "run once" and in "Boot Options" check the "Enable menu to select boot device" checkbox and also the "Start in Pause Mode". This makes the VM pause at the very beginning. Connect the console to it and unpause it and enter the boot menu (press ESC in the SPICE window). And let us know what is listed there. Thank you. Created attachment 1252784 [details]
boot problem screenshot
screenshot of the boot problem after disk selection from the boot menu
Hi Tomas, VirtIO-SCSI is enabled Hard Disk is the first in boot options (i did not touch this value) it does not matter if the disks are in one storage domain or different one. i tried to create a new vm with one attached disk (ubuntu cloud image and one created disk) and created a new vm from template (the template has identical settings) with no difference I have tested it on oVirt 4.0 and 4.1 (different installations) could it be somehow connected with the naming of the disk? BR Stefan I was trying with various setups with various disks and Im still unable to simulate this... but still, there are two options: 1: either engine sends the wrong boot order, or 2: some issue with the lower layers To check a bit more the first: When looking at the logs I see only attempts with two virtio scsi disks. Could you please provide for comparision an engine log when only one bootable disk is there so the VM boots properly and one where there are two so it does not? To check a bit more the second: Please provide for both runs (with one disk and with two) the output of virsh -r dumpxml <vm name> from the host when the VM is running. Also please attach the libvirt and qemu logs (I don't expect much there, but...) Thank you Tomas Created attachment 1256503 [details]
virsh xml dump, enginelog and qemu log
virsh dumpxml, enginelog and qemu log
Hi Tomas, this time it was quite hard to reproduce the problem so you will find a lot of entries in the logs with the same machine names. In the end i was "successfull". here are the timestamps: 2017-02-22 14:47:26 copy root disk finished 2017-02-22 14:48:13 create new vm called testboot with attached root disk and an newly create log 2017-02-22 14:51:43 clone machine testboot2 2017-02-22 14:52:28,026 "run once" testboot2 -> machine is booting "run once" testboot -> machine is NOT booting As far as i can see the problem appears whenever the boot disk is not on scsi scsi0-0-0-0. I have double checked the results with my 3 disk template and got the same result: whenever the boot disk is on scsi0-0-0-0 it is booting. Stefan So, to determine which disk is the boot we have 2 "flags": 1: the "isBoot" flag on disk 2: the "bootOrder" on device If the disk (attachment) has isBoot==true (in engine DB) we send "index=0" to VDSM. If it's device has bootOrder > 0 (in engine DB) we send the "bootOrder=N" to the VDSM. (simplifying here, but more or less...) so, what I see in the logs: ------------------------------------------------------- testboot2: the boot image ID is 74766bda-8c9c-4c61-aa9b-149da942c9df because: - The isBoot is true for it since the logs contain: Bootable disk '74766bda-8c9c-4c61-aa9b-149da942c9df' set to index '0' - The bootOrder == 1 since we send bootOrder=1 e.g. the for this VM the boot disk is the 74766bda-8c9c-4c61-aa9b-149da942c9df and it is correctly configured on both device and disk (attachment). ------------------------------------------------------- testboot: the boot image ID is 5c1c497a-20f2-49b9-a961-dae95516a411 because: - The isBoot is true for it since the logs contain: Bootable disk '5c1c497a-20f2-49b9-a961-dae95516a411f' set to index '0' - The bootOrder == 1 since we send bootOrder=1 e.g. the for this VM the boot disk is the 5c1c497a-20f2-49b9-a961-dae95516a411 and it is correctly configured on both device and disk (attachment). ------------------------------------------------------- So, long story short, it really looks like for this two VMs you have different disks configured as boot disks while from one the VM boots properly and from the other not. Can you please double check in the VM main tab -> pick VM -> check the disks sub tab which disk is configured as bootable? For testboot and testboot2 it should be different disks (at least this is what the logs are telling me). double checked: the larger disks with 10GB and the alias "root" have the OS(isbootable) flag set @Karen: it seems that if you have more virtio-scsi disks than the bootindex is ignored and always the one which is on scsi0-0-0-0 is booting. Do you know if there is some limitation or bug around this in qemu? (In reply to Tomas Jelinek from comment #11) > @Karen: > it seems that if you have more virtio-scsi disks than the bootindex is > ignored and always the one which is on scsi0-0-0-0 is booting. Do you know > if there is some limitation or bug around this in qemu? Paolo? Hey Paolo, any news? What is the QEMU command line? Paolo, you can look at the attached "virsh xml dump, enginelog and qemu log". Of the two virtio-scsi disks, only one has a <boot order="1"> element. Therefore, the other disk is not part of the boot order. right. And the one which has the <boot order="1"> is the disk we need to boot from. Yet, it does not boot from it, unless it is on scsi0-0-0-0. Please try putting it on target 1 LUN 0 instead of target 0 LUN 1, that should work. Usually with real hardware separate disks will be assigned to separate targets rather than separate LUNs. If that works, this is bug 1020622. (In reply to Paolo Bonzini from comment #18) > Please try putting it on target 1 LUN 0 instead of target 0 LUN 1, that > should work. Usually with real hardware separate disks will be assigned to > separate targets rather than separate LUNs. > > If that works, this is bug 1020622. Tomas, is that the case? indeed, it is the case. Moving to storage to decide if changing the address assignment as per comment 18 is something we want to do or not. @Stefan: to work around this issue, you can go to DB to vm_device table and update the address field. I don't see any reason to change it since the bug is in the fact that LUN 1 cannot be boot from thus it's should be dependent on bug 1020622 This bug depends on the platform bug 1020622, which is targeted to RHEL 7.4. Pushing out to oVirt 4.2 when a proper fix from the platform should hopefully be available. (In reply to Allon Mureinik from comment #22) > This bug depends on the platform bug 1020622, which is targeted to RHEL 7.4. > Pushing out to oVirt 4.2 when a proper fix from the platform should > hopefully be available. Tal, is there any AI for us besides requiring this fix? (In reply to Allon Mureinik from comment #23) > (In reply to Allon Mureinik from comment #22) > > This bug depends on the platform bug 1020622, which is targeted to RHEL 7.4. > > Pushing out to oVirt 4.2 when a proper fix from the platform should > > hopefully be available. > Tal, is there any AI for us besides requiring this fix? No, that should fix the bug (In reply to Tal Nisan from comment #24) > (In reply to Allon Mureinik from comment #23) > > (In reply to Allon Mureinik from comment #22) > > > This bug depends on the platform bug 1020622, which is targeted to RHEL 7.4. > > > Pushing out to oVirt 4.2 when a proper fix from the platform should > > > hopefully be available. > > Tal, is there any AI for us besides requiring this fix? > > No, that should fix the bug I'm not sure I understand the issue here, but: If the host should require it, please send a patch to vdsm's spec file. If the guest should require it, it's up to the guest to use an updated bios, and this BZ should be closed. Do I get it right that RHV 4.2 should address this issue? We are currently using RHV 4.1 (GSS ticket #01908243) and also affected. It's not about the guest, QEMU uses the SeaBIOS binary when running the VM so I guess QEMU should require it. I've checked and for RHEL/Centos 7.4 the fixed package is available but it seems that not in Fedora (In reply to Tal Nisan from comment #27) > It's not about the guest, QEMU uses the SeaBIOS binary when running the VM > so I guess QEMU should require it. Agreed. Moving this bug to qemu-kvm-rhev so their devs can decide if they want to bump the requirement to seabios>=1.10.2-3.el7 (In reply to Allon Mureinik from comment #28) > (In reply to Tal Nisan from comment #27) > > It's not about the guest, QEMU uses the SeaBIOS binary when running the VM > > so I guess QEMU should require it. > > Agreed. > Moving this bug to qemu-kvm-rhev so their devs can decide if they want to > bump the requirement to seabios>=1.10.2-3.el7 I do not believe anything is needed. That seabios version was released in 7.4 GA so all 7.4 hosts have that, so all RHV 4.1 hosts have that. F26 is not a supported host OS so that's irrelevant. Isn't RHV 4.1 based on 7.4 GA? *** This bug has been marked as a duplicate of bug 1020622 *** |