When attempting to install onto a SCSI disk (using libvirt through virt-manager), the installer does not detect the disk as an install target. However, if I put it on a different bus (e.g., VirtIO), it detects and installs fine, and I can then move the disk onto SCSI and my system will continue working. Of note - installation onto SCSI media is working in the same setup on Fedora23 (and possibly other versions as well; I have not checked). Thanks!
Please attach the logs from /tmp in the installer environment.
Created attachment 1119481 [details] *.log from /tmp Here are the requested logs from /tmp.
Created attachment 1119484 [details] program.log extracted from tmp_logs.tar.gz
Created attachment 1119485 [details] packaging.log extracted from tmp_logs.tar.gz
Created attachment 1119486 [details] storage.log extracted from tmp_logs.tar.gz
Created attachment 1119488 [details] ifcfg.log extracted from tmp_logs.tar.gz
Created attachment 1119489 [details] X.log extracted from tmp_logs.tar.gz
Created attachment 1119490 [details] anaconda.log extracted from tmp_logs.tar.gz
Please also attach /tmp/syslog. It looks like the disk is not being detected by the kernel, and, trying this myself, I don't see virtual HBA being detected. The virtio_scsi module is present but is not being automatically loaded, and loading it does not appear to change anything.
Created attachment 1119497 [details] /tmp/syslog Sure thing. Hope this helps!
Can you provide the domain XML (virsh dumpxml <domain>) and log (/var/log/libvirt/qemu/<domain>.log) too? Are there any instructions to reproduce this issue?
Created attachment 1129405 [details] domain xml
Created attachment 1129406 [details] domain log
(In reply to Fam Zheng from comment #13) > Can you provide the domain XML (virsh dumpxml <domain>) and log > (/var/log/libvirt/qemu/<domain>.log) too? Should be attached now. > Are there any instructions to reproduce this issue? Use virt-manager to create a RHEL-7.2 machine with disk on SCSI. Installer will fail to find it. I don't think this is a virt bug because if I proceed to install onto VirtIO, then switch the disk from VirtIO to SCSI, the resulting system continues to boot just fine.
(In reply to Robbie Harwood from comment #16) > I don't think this is a virt bug because if I proceed to install onto > VirtIO, then switch the disk from VirtIO to SCSI, the resulting system > continues to boot just fine. (Not entirely true - the system gets most of the way though booting before dracut can't find the disk by UUID.)
The domain xml says a "scsi" controller is selected which is translated as "lsi" in the QEMU command line, according to the domain log. The expected controller type is virtio-scsi. This is also what I see on my machine. So, this is probably either a virt-manager issue, or a misconfiguration. In virt-manager, what "Model" do you see in the scsi controller? If it is configurable, what are the other options?
(In reply to Fam Zheng from comment #18) > The domain xml says a "scsi" controller is selected which is translated as > "lsi" in the QEMU command line, according to the domain log. > > The expected controller type is virtio-scsi. This is also what I see on my > machine. > > So, this is probably either a virt-manager issue, or a misconfiguration. > > In virt-manager, what "Model" do you see in the scsi controller? If it is > configurable, what are the other options? Model is set to "hypervisor default". The only other option is "VirtIO SCSI". Confusingly, if I set it to "VirtIO SCSI", then the installer finds the disk. This sounds like a virt-manager issue then?
Can you report the virt-manager version, please? The guest kernel works well with virtio-scsi HBA, because that is the common option here. The "hypervisor default", which ended up as an LSI HBA for you, seems that requires additional driver configuration during installation. And yes, this is a question for virt-manager. I'm moving the component so that we can have some input from virt-manager developers.
(In reply to Fam Zheng from comment #20) > Can you report the virt-manager version, please? virt-manager version 1.2.1 provided the logs, though the problem also occurs with 1.13.2. > The guest kernel works well with virtio-scsi HBA, because that is the common > option here. The "hypervisor default", which ended up as an LSI HBA for you, Thanks for explaining!
Based on the domain XML you are probably using upstream QEMU, there is no machine 'pc-i440fx-2.5' in RHEL's QEMU. Anyway, this is not even a bug. If you don't specify any controller model "Hypervisor default" libvirt will set the default model based on what current QEMU provides and lsi has higher priority than virtio-scsi. This wouldn't happen for RHEL QEMU, because there is no 'lsi' device, only 'virtio-scsi' device. However, upstream QEMU has the 'lsi' device.
virt-manager doesn't provide me a handle to specify a controller model. I don't see how this can not be a bug when it creates something that looks like it should work and doesn't. Retargeting to Fedora virt-manager.
(In reply to Robbie Harwood from comment #23) > virt-manager doesn't provide me a handle to specify a controller model. I > don't see how this can not be a bug when it creates something that looks > like it should work and doesn't. you can definitely specify a controller model in rawhide virt-manager: both via the add hardware, and via the VM window 'details' page for a scsi controller... am I missing something?
(In reply to Cole Robinson from comment #24) > you can definitely specify a controller model in rawhide virt-manager: both > via the add hardware, and via the VM window 'details' page for a scsi > controller... ...the latter of which is available from the new VM wizard via the 'customize before install' option on the last page
Apologies, I should have been more thorough. Yes, you definitely can specify a controller. Can we please change the default to something that RHEL will work with?
Yes, that's a good idea. Typically we only use OS defaults for actual default devices and not manually added bits, but it makes sense to adjust things here
There's been a lot of changes over the years to make sure newly added devices use the optimal defaults for the attached VM. At some point this specific issue was fixed but I didn't narrow down the commit. Should be available in v2.1.0 at least, although it requires the VM has an OS listed in the XML (OS Information section of VM Details window)