Created attachment 1645617 [details]
rhel6.10 q35 qemu cmdline
Description of problem:
Rhel6.10 VM with default configuration (q35 chipset - cluster Default) is unusable. Kernel panic emerges during boot process.
Version-Release number of selected component (if applicable):
guest (rhel6.10 (20180613 latest compose)):
Steps to Reproduce:
1.Create rhel6 VM in RHV4.4 (choose Operating system as Red Hat Enterprise Linux 6.x x64)
2. boot VM
VM starts, but Kernel panic occurs during boot process
VM starts successfully
If I make rhel6 VM with i440-fx chipset ("Edit virtual machine" -> System -> Custom emulated machine: pc-i440fx-rhel7.6.0) instead of q35, VM is working ok.
* this is regression since in rhv4.3 was cluster Default i440-fx chipset
Created attachment 1645618 [details]
Please test in 4.4.0-9, and make sure the Cluster you are creating has a concrete CPU set - do not use auto detection
I tested with 4.4.0-9 with the same result.
I do not see any possibility for CPU set auto detection.
I have Cluster setting like this:
Cluster CPU Type:
Intel SandyBridge Family
Q35 is only partly supported in RHEL6, but should boot. Can we get a screenshot of the panic?
(In reply to Ryan Barry from comment #15)
> Q35 is only partly supported in RHEL6, but should boot. Can we get a
> screenshot of the panic?
It is already attached
Sorry, let me be clearer. The screenshot of the panic does not give enough information. The cmdline is not the kernel cmdline used, and it's not clear whether this comes from a template, fresh install with Anaconda, or other. What is the exact reproducer?
Created attachment 1649180 [details]
rhel6 libvirt xml
See also https://bugzilla.redhat.com/show_bug.cgi?id=1380285 - legacy virtio is needed for RHEL 6 guests.
if that's enough then it's as "complex" as blocking rhel 6, so let's give it a try with legacy virtio
For me it works on master.
I created VM with RHEL 6.10, q35 chipset (also tried to create one from if440x template).
Boot passed without kernel panic.
I got a warning on the CPU when booting (Skylake, which isn't signed and unrecognized for el6).
Another issue was booting with Virtio or Virtio-SCSI as the interface to the disk.
In this scenario I did encountered kernel panic.
I tried, after Michal suggestion to add model=virtio-transitional to the disk while using VirtIO to use legacy virtio (https://libvirt.org/formatdomain.html#elementsVirtioTransitional).
<disk snapshot="no" type="file" device="disk">
<target dev="vda" bus="virtio"/>
<seclabel model="dac" type="none" relabel="no"/>
<driver name="qemu" iothread="1" io="threads" type="qcow2" error_policy="stop" cache="none" model="virtio-transitional"/>
libvirt domxml as return:
<disk type='file' device='disk' snapshot='no'>
<driver name='qemu' type='qcow2' cache='none' error_policy='stop' io='threads' iothread='1'/>
<seclabel model='dac' relabel='no'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
This still resulted still the same.
For what it worth, maybe asking virt what is the expected behavior for model="virtio-transitional", because it was thrown.
As for RHEV, we can set by default SATA as disk interface for Q35 chipset, or maybe make Virtio/Virtio-SCSI invalid for VMs with OS older than el7.
After a small discussion with libvirt guys.
I was setting the attribute to the wrong value.
- model="virtio-transitional" should be added to the disk element.
After setting it manually, the VM goes up with Q35 and Virtio.
moving to 4.4.0, due to regression keyword
will probably fix in time, but just in case, moving to 4.4.1, It's not a regression RHEL 6 was never supported on Q35 because Q35 wasn't supported at all in <4.4
Moving back to POST. SCSI disk isn't supported and caused a regression. A new patch fixing it is posted.
(In reply to Liran Rotenberg from comment #28)
> Moving back to POST. SCSI disk isn't supported and caused a regression. A
> new patch fixing it is posted.
Just to clarify, automation test cases which created VM with RHEL6 + virtio/virtio_iscsi disks encountered this issue.
Meaning RHEL6 OS_TYPE VM's did not boot up.
Liran saw the issue, debugged and issued a patch to fix it.
Issue seen at:
I'm moving it back to ASSIGNED.
The next build will resolve disk using VirtIO and the regression to RHV QE.
Using VirtIO-SCSI is possible if the controller device is changed.
Also, some other devices might need it to support the VM OS.
1. Run RHEL 6 VM with cluster default (Q35 chipset) and VirtIO disk interface.
Verify VM is booting.
2. Run RHEL 6 VM with cluster default and VirtIO-SCSI disk interface.
Verify VM is booting.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.