Is there a specific edition (AS/ES) or architecture (x86/x64/ia64) that this issue is being experienced on?

The particular iso in question is:
RHEL4-RC-re0107.0-x86_64-ES-DVD-ftp.iso

which is ES and arch: x86_64

I haven't tried other combinations.

did you succeed with a regular run? Did you succeed with virt-manager? If yes, what's the qemu cmdline? Can you compare and try to remove non-essential devices?
I'm not sure if e.g. virtio-balloon works at all in RHEL 4. Also qemu-wise the machine type "-M rhel6.5.0" may not be the right one.

I was able to install and run RHEL4 successfully when doing a PXE boot, attaching a CD always led to a kernel panic, right after the installation process was attempted (right after hitting Enter to attempt an install in graphical mode).

Here is the qemu-kvm command line when using PXE, which works successfully:
/usr/libexec/qemu-kvm -name RHEL4RC -S -M rhel6.5.0 -cpu Opteron_G3 -enable-kvm -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 8e65458e-9e33-4a70-a6c5-a0abc6c72a33 -smbios type=1,manufacturer=Red Hat,product=RHEV Hypervisor,version=6Server-6.5.0.0.el6,serial=8AA6FB90-56CB-1020-0519-153434000000,uuid=8e65458e-9e33-4a70-a6c5-a0abc6c72a33 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/RHEL4RC.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2013-11-11T15:49:19,driftfix=slew -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/mnt/blockSD/3bf77a26-3a5a-4d29-8952-31e98dcc4753/images/a2785043-4705-41c5-aa45-9f1ccfc0da1c/c71468a0-58fa-4795-93e4-1abe1c674a34,if=none,id=drive-virtio-disk0,format=raw,serial=a2785043-4705-41c5-aa45-9f1ccfc0da1c,cache=none,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -netdev tap,fd=31,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=00:1a:4a:dc:ca:d9,bus=pci.0,addr=0x3,bootindex=1 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/8e65458e-9e33-4a70-a6c5-a0abc6c72a33.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/8e65458e-9e33-4a70-a6c5-a0abc6c72a33.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel2,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0 -spice port=5902,tls-port=5903,addr=0,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on -k en-us -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=33554432 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8

So virt manager was successful and RHEV Manager wasn't.
Was there a difference in the config - eg. did you enable spice in virt-manager?

Please post the libvirt xml for the working virt-manager installation

thanks

In Comment 4, I meant I was successfully doing a PXE installation using RHEVM (qemu cmd line in Comment4), and I was getting a kernel panic when attempting to do a run once in RHEVM (qemu cmd line in original bug report) also.

Please use virsh to dump the domain XML from the working VM (on VirtManager) and from the one from RHEVM which is crashing.

you can get it by using virsh -r dumpxml NAME_OF_THE_VM

thanks.

Created attachment 823995 [details]
virsh dump of failing RHEL4 RunOnce VM

Created attachment 823996 [details]
virsh dump of successful RHEL4 (used PXE)

Hi,

I was unable to get a virsh dump using virt-manager, that machine I was using has been rebuilt to RHEL 7 for other testing.

I attached the virsh dump of a successfull RHEL4 VM in RHEVM is19, which would only work if I used PXE to install it.

I attached the virsh dump of the failing RHEL4 VM in RHEVM is19, which kernel panics, when using Run Once and attaching the RHEL 4 iso, after selecting to Install it.

We need this issue reproduced.  It appears the only difference between the VMs is the sound card definition, which is also interesting.

Meital, can you verify that testing RHEL 4 Guest installation is on the test matrix for 3.3?

(In reply to Scott Herold from comment #11)
> We need this issue reproduced.  It appears the only difference between the
> VMs is the sound card definition, which is also interesting.
> 
> Meital, can you verify that testing RHEL 4 Guest installation is on the test
> matrix for 3.3?

After talking to Meital, we don't have RHEL 4 guest installation in our RHEVM 3.3 test matrix. 
But we'll try to reproduce this issue with the RHEL4-RC-re0107.0-x86_64-ES-DVD-ftp.iso.

(In reply to Scott Herold from comment #11)
> We need this issue reproduced.  It appears the only difference between the
> VMs is the sound card definition, which is also interesting.

Sadly it does not seem to be the sound card. I tried it with both devices and it didn't fail on pxe.

@vipatel:
I am not sure why but with that ISO you had attached I am not able to actually start the installation. Because it can't find any "Hard Drive" even though an attached was there. However it does not panic.

On our PXE boot environment I had no such issues. I was able to install RHEL4 and boot afterwards with zero problems.

Another issue might be related to the fact that I don't have any Opteron CPU available for testing, so it is quite possible that the issue is related to this.

However I have excluded all reasons which could be related to RHEVM. And considering that you have actually a working version on RHEVM points rather to some driver issue on RHEL4 or a kvm issue related to AMD chipsets.

Please specify your hardware, where you have reproduced this.
Please also specify version of your Kernel, qemu version, libvirt version and for the sake of completeness version of VDSM.

Additionally please attach the log files of the failing VM from /var/log/libvirt/qemu/ 

Thanks.

Our RHEVM instance is in the middle of an upgrade, I will get you this information on a later build probably next week.  Thanks.

(In reply to Vinzenz Feenstra [evilissimo] from comment #13)
> (In reply to Scott Herold from comment #11)
> > We need this issue reproduced.  It appears the only difference between the
> > VMs is the sound card definition, which is also interesting.
> 
> Sadly it does not seem to be the sound card. I tried it with both devices
> and it didn't fail on pxe.
> 
> @vipatel:
> I am not sure why but with that ISO you had attached I am not able to
> actually start the installation. Because it can't find any "Hard Drive" even
> though an attached was there. However it does not panic.

For RHEL systems, I usually set the hard drive to VirtIO, but for RHEL 4, I guess it needs to be IDE, a BRNO instance was able to get RHEL 4 running using the iso, and using Run Once with IDE, I am still unable to get this working, I am still seeing a kernel panic whether I choose IDE or VirtIO. I thought it may have been a bad iso on our end, but I did an md5sum on both isos and they were identical.  So the issue has to be something unique to our setup.

> 
> On our PXE boot environment I had no such issues. I was able to install
> RHEL4 and boot afterwards with zero problems.
Same here I am able to PXE boot RHEL w/ no issues, the only problem I have is run once with the ISO.

> 
> Another issue might be related to the fact that I don't have any Opteron CPU
> available for testing, so it is quite possible that the issue is related to
> this.
If you want access to our instance to see what I am seeing, please let me know.

> 
> However I have excluded all reasons which could be related to RHEVM. And
> considering that you have actually a working version on RHEVM points rather
> to some driver issue on RHEL4 or a kvm issue related to AMD chipsets.
I don't think our RHEVM is the issue we have done plenty of installs with Windows 7, RHEL6, RHEL7, and we haven't seen any VM creation issues.

> 
> Please specify your hardware, where you have reproduced this.
> Please also specify version of your Kernel, qemu version, libvirt version
> and for the sake of completeness version of VDSM.

Hardware Info:
AMD Opteron G3

Host information:
kernel-2.6.32-431.el6.x86_64
vdsm-4.13.0-0.8.beta1.el6ev.x86_64
libvirt-0.10.2-29.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.414.el6.x86_64

RHEVM information:
kernel-2.6.32-131.6.1.el6.x86_64

> 
> Additionally please attach the log files of the failing VM from
> /var/log/libvirt/qemu/ 
> 
I will attach the log to this bug.
> Thanks.

Forgot to mention the I reproduced against a later version of RHEVM, is23.1 (http://bob.eng.lab.tlv.redhat.com/builds/is23.1/)

I tried to attach the qemu log file for RHEL 4, but it kept failing for some reason, I added it to pastebin: http://pastebin.test.redhat.com/178081

So we tried our best to reproduce this, I was not able to reproduce this with the RHEL4-RC-re0107.0-x86_64-ES-DVD-ftp.iso in any case.

We even have had setup an environment on Opteron processors where we had no problem and were not able to reproduce this issue.

Either this issue is specific to your environment, or there's an issue in some specific RHEL4 driver which is not reproducible for us.

Vimal, I would close this bug as this really is not getting anywhere for us. We have no problems with RHEL4 as guests whatsoever we tried.

Created attachment 834369 [details]
qemu log file

I have localized this issue on the following line:

<model fallback='allow'>Opteron_G3</model>

Here's some info from the Host:

virsh # sysinfo
<sysinfo type='smbios'>
  <bios>
    <entry name='vendor'>American Megatrends Inc.</entry>
    <entry name='version'>P01-A2</entry>
    <entry name='date'>04/21/2010</entry>
    <entry name='release'>8.15</entry>
  </bios>
  <system>
    <entry name='manufacturer'>Acer</entry>
    <entry name='product'>Aspire M3400</entry>
    <entry name='version'>        </entry>
    <entry name='serial'>PTSE0020140200937F2700</entry>
    <entry name='uuid'>8AA6FB90-56CB-1020-0519-153434000000</entry>
    <entry name='sku'>To Be Filled By O.E.M.</entry>
    <entry name='family'>Acer Desktop</entry>
  </system>
  <processor>
    <entry name='socket_destination'>CPU 1</entry>
    <entry name='type'>Central Processor</entry>
    <entry name='family'>Phenom II</entry>
    <entry name='manufacturer'>AMD</entry>
    <entry name='signature'>Family 16, Model 4, Stepping 2</entry>
    <entry name='version'>AMD Phenom(tm) II X4 820 Processor</entry>
    <entry name='external_clock'>200 MHz</entry>
    <entry name='max_speed'>2800 MHz</entry>
    <entry name='status'>Populated, Enabled</entry>
    <entry name='serial_number'>To Be Filled By O.E.M.</entry>
    <entry name='part_number'>To Be Filled By O.E.M.</entry>
  </processor>
  <memory_device>
    <entry name='size'>2048 MB</entry>
    <entry name='form_factor'>DIMM</entry>
    <entry name='locator'>DIMM0</entry>
    <entry name='bank_locator'>BANK0</entry>
    <entry name='type'>DDR3</entry>
    <entry name='type_detail'>Synchronous</entry>
    <entry name='speed'>533 MHz</entry>
    <entry name='manufacturer'>Nanya</entry>
    <entry name='serial_number'>62196374</entry>
    <entry name='part_number'>M2Y2G64CB8HC5N-CG</entry>
  </memory_device>
  <memory_device>
    <entry name='size'>2048 MB</entry>
    <entry name='form_factor'>DIMM</entry>
    <entry name='locator'>DIMM1</entry>
    <entry name='bank_locator'>BANK1</entry>
    <entry name='type'>DDR3</entry>
    <entry name='type_detail'>Synchronous</entry>
    <entry name='speed'>533 MHz</entry>
    <entry name='manufacturer'>Nanya</entry>
    <entry name='serial_number'>6219683B</entry>
    <entry name='part_number'>M2Y2G64CB8HC5N-CG</entry>
  </memory_device>
  <memory_device>
    <entry name='size'>2048 MB</entry>
    <entry name='form_factor'>DIMM</entry>
    <entry name='locator'>DIMM2</entry>
    <entry name='bank_locator'>BANK2</entry>
    <entry name='type'>DDR3</entry>
    <entry name='type_detail'>Synchronous</entry>
    <entry name='speed'>533 MHz</entry>
    <entry name='manufacturer'>Kingston</entry>
    <entry name='serial_number'>BBD81C0B</entry>
    <entry name='part_number'>ACR256X64D3U1333C9</entry>
  </memory_device>
  <memory_device>
    <entry name='size'>2048 MB</entry>
    <entry name='form_factor'>DIMM</entry>
    <entry name='locator'>DIMM3</entry>
    <entry name='bank_locator'>BANK3</entry>
    <entry name='type'>DDR3</entry>
    <entry name='type_detail'>Synchronous</entry>
    <entry name='speed'>533 MHz</entry>
    <entry name='manufacturer'>Kingston</entry>
    <entry name='serial_number'>BC4E1C0B</entry>
    <entry name='part_number'>ACR256X64D3U1333C9</entry>
  </memory_device>
</sysinfo>

virsh # capabilities 
<capabilities>

  <host>
    <uuid>a7eb59e0-c1c7-487a-b840-f30f92823527</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>Opteron_G3</model>
      <vendor>AMD</vendor>
      <topology sockets='1' cores='4' threads='1'/>
      <feature name='wdt'/>
      <feature name='skinit'/>
      <feature name='ibs'/>
      <feature name='osvw'/>
      <feature name='3dnowprefetch'/>
      <feature name='cr8legacy'/>
      <feature name='extapic'/>
      <feature name='cmp_legacy'/>
      <feature name='3dnow'/>
      <feature name='3dnowext'/>
      <feature name='pdpe1gb'/>
      <feature name='fxsr_opt'/>
      <feature name='mmxext'/>
      <feature name='ht'/>
      <feature name='vme'/>
    </cpu>
    <power_management>
      <suspend_mem/>
      <suspend_disk/>
    </power_management>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='1'>
        <cell id='0'>
          <cpus num='4'>
            <cpu id='0' socket_id='0' core_id='0' siblings='0'/>
            <cpu id='1' socket_id='0' core_id='1' siblings='1'/>
            <cpu id='2' socket_id='0' core_id='2' siblings='2'/>
            <cpu id='3' socket_id='0' core_id='3' siblings='3'/>
          </cpus>
        </cell>
      </cells>
    </topology>
    <secmodel>
      <model>selinux</model>
      <doi>0</doi>
    </secmodel>
    <secmodel>
      <model>dac</model>
      <doi>0</doi>
    </secmodel>
  </host>

  <guest>
    <os_type>hvm</os_type>
    <arch name='i686'>
      <wordsize>32</wordsize>
      <emulator>/usr/libexec/qemu-kvm</emulator>
      <machine>rhel6.5.0</machine>
      <machine canonical='rhel6.5.0'>pc</machine>
      <machine>rhel6.4.0</machine>
      <machine>rhel6.3.0</machine>
      <machine>rhel6.2.0</machine>
      <machine>rhel6.1.0</machine>
      <machine>rhel6.0.0</machine>
      <machine>rhel5.5.0</machine>
      <machine>rhel5.4.4</machine>
      <machine>rhel5.4.0</machine>
      <domain type='qemu'>
      </domain>
      <domain type='kvm'>
        <emulator>/usr/libexec/qemu-kvm</emulator>
      </domain>
    </arch>
    <features>
      <cpuselection/>
      <deviceboot/>
      <acpi default='on' toggle='yes'/>
      <apic default='on' toggle='no'/>
      <pae/>
      <nonpae/>
    </features>
  </guest>

  <guest>
    <os_type>hvm</os_type>
    <arch name='x86_64'>
      <wordsize>64</wordsize>
      <emulator>/usr/libexec/qemu-kvm</emulator>
      <machine>rhel6.5.0</machine>
      <machine canonical='rhel6.5.0'>pc</machine>
      <machine>rhel6.4.0</machine>
      <machine>rhel6.3.0</machine>
      <machine>rhel6.2.0</machine>
      <machine>rhel6.1.0</machine>
      <machine>rhel6.0.0</machine>
      <machine>rhel5.5.0</machine>
      <machine>rhel5.4.4</machine>
      <machine>rhel5.4.0</machine>
      <domain type='qemu'>
      </domain>
      <domain type='kvm'>
        <emulator>/usr/libexec/qemu-kvm</emulator>
      </domain>
    </arch>
    <features>
      <cpuselection/>
      <deviceboot/>
      <acpi default='on' toggle='yes'/>
      <apic default='on' toggle='no'/>
    </features>
  </guest>

</capabilities>


virsh # 
[root@salusa ~]# cat /proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X4 820 Processor
stepping	: 2
cpu MHz		: 2800.000
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save
bogomips	: 5600.30
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X4 820 Processor
stepping	: 2
cpu MHz		: 2800.000
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 4
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save
bogomips	: 5600.30
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor	: 2
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X4 820 Processor
stepping	: 2
cpu MHz		: 2800.000
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 2
cpu cores	: 4
apicid		: 2
initial apicid	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save
bogomips	: 5600.30
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor	: 3
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X4 820 Processor
stepping	: 2
cpu MHz		: 2800.000
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save
bogomips	: 5600.30
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

virsh # nodeinfo 
CPU model:           x86_64
CPU(s):              4
CPU frequency:       2800 MHz
CPU socket(s):       1
Core(s) per socket:  4
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         8175432 KiB

(In reply to Vinzenz Feenstra [evilissimo] from comment #21)
> I have localized this issue on the following line:
> 
> <model fallback='allow'>Opteron_G3</model>
> 

Good job isolating the problem. Can anybody from virt-QE reproduce this problem in one of our machines?

(removing stale needinfo())

Comment #0 has very little information about the actual error messages, but I think I managed to reproduce it. When booting the RHEL4 ISO using the command-line from comment #0 I get the following guest panic:

MCE: warning: using only 10 banks
general protection fault: 0000 [1]
CPU 0
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.9-5.EL
RIP: 0010:[<ffffffff801190ea>] <ffffffff801190ea>{mce_init+139}
RSP: 0018:ffffffff8051ffd0  EFLAGS: 00010217
RAX: fffffffffffffbff RBX: 000000000100010a RCX: 0000000000000410
RDX: 00000000ffffffff RSI: 0000000000000001 RDI: 0000000000000010
RBP: 0000000000000000 R08: ffffffff8040f160 R09: 0000000000000000
R10: ffffffff8051ff40 R11: 0000000000000048 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff8051c900(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000101000 CR4: 00000000000006e0
Process swapper (pid: 0, threadinfo ffffffff8051e000, task ffffffff8040ab80)
Stack: 0000000000000800 ffffffff805216ca ffffffff804925e0 ffffffff805211ab
       0000000000000000 0000000000000000
Call Trace:<ffffffff805216ca>{start_kernel+591} <ffffffff805211ab>{_sinittext+427}


Code: 0f 30 31 c0 8d 8f 01 04 00 00 31 d2 0f 30 83 c7 04 49 83 c0
RIP <ffffffff801190ea>{mce_init+139} RSP <ffffffff8051ffd0>
 <0>Kernel panic - not syncing: Attempted to kill the idle task!
 
 

The guest panic is not reproduced if omitting the "-cpu Opteron_G3" option.


There's an easy work around for the bug: using the "nomce" kernel command-line option on the RHEL4 ISO bootloader prompt.


Bug is still open because I am investigating why GP is raised. The faulting instruction is wrmsr, but the data shown on EDX:EAX and ECX looks OK to me. Guest is trying to write to MSR 0x410 (MSR_IA32_MC0_CTL + 0x10).

As it has an easy workaround and is only reproduced using a RHEL4 guest, closing as WONTFIX.

Found the upstream fix:

commit 114be429c8cd44e57f312af2bbd6734e5a185b0d
Author: Andre Przywara <andre.przywara>
Date:   Wed Mar 24 17:46:42 2010 +0100

    KVM: allow bit 10 to be cleared in MSR_IA32_MC4_CTL

    There is a quirk for AMD K8 CPUs in many Linux kernels (see
    arch/x86/kernel/cpu/mcheck/mce.c:__mcheck_cpu_apply_quirks()) that
    clears bit 10 in that MCE related MSR. KVM can only cope with all
    zeros or all ones, so it will inject a #GP into the guest, which
    will let it panic.
    So lets add a quirk to the quirk and ignore this single cleared bit.
    This fixes -cpu kvm64 on all machines and -cpu host on K8 machines
    with some guest Linux kernels.

    Signed-off-by: Andre Przywara <andre.przywara>
    Signed-off-by: Avi Kivity <avi>

This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Patch(es) available on kernel-2.6.32-521.el6

with kernel-2.6.32-504.el6.x86_64, guest panic right after hit enter in cdrom booting
with kernel-2.6.32-538.el6.x86_64, guest would continue installer and ask whether to check disc.



with qemu-kvm-rhev-0.12.1.2-2.454.el6.x86_64
cli:

/usr/bin/qemu-kvm -monitor stdio \
    -S  \
    -name 'virt-tests-vm1' \
    -M rhel6.5.0  \
    -nodefaults  \
    -vga cirrus \
    -realtime mlock=off \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20150302-144938-ZH8MdVVp,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150302-144938-ZH8MdVVp,server,nowait \
    -device isa-serial,chardev=serial_id_serial0  \
    -chardev socket,id=seabioslog_id_20150302-144938-ZH8MdVVp,path=/tmp/seabios-20150302-144938-ZH8MdVVp,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20150302-144938-ZH8MdVVp,iobase=0x402 \
    -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=04 \
    -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/usr/local/staf/test/RHEV/kvm/autotest-devel/client/tests/virt/shared/data/images/rhel49-64-virtio.qcow2 \
    -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=05 \
    -device e1000,mac=9a:9c:9d:9e:9f:a0,id=idiJeIqf,netdev=idMjY8YG,bus=pci.0,addr=06  \
    -netdev tap,id=idMjY8YG,vhost=on  \
    -m 4096  \
    -smp 1,maxcpus=1,cores=1,threads=1,sockets=1  \
    -cpu 'Opteron_G3' \
    -drive id=drive_cd1,if=none,snapshot=off,aio=native,media=cdrom,file="/home/RHEL4-RC-re0107.0-x86_64-ES-DVD-ftp.iso" \
    -device ide-drive,id=cd1,drive=drive_cd1,bootindex=2,bus=ide.0,unit=0 \
    -drive id=drive_fl,if=none,cache=none,snapshot=off,readonly=off,aio=native,file=/usr/local/staf/test/RHEV/kvm/autotest-devel/client/tests/virt/shared/data/images/rhel49-64/ks.vfd \
    -global isa-fdc.driveA=drive_fl \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -vnc :0  \
    -rtc base=utc,clock=host,driftfix=slew  \
    -boot d \
    -no-shutdown \
    -enable-kvm  \
    -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8


Based on above info,
move to VERIFIED

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, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-1272.html