Bug 497356
Summary: | HVM-PV RHEL5.3 panics post-install with Solaris dom0 | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | John Levon <levon> | ||||
Component: | kernel-xen | Assignee: | Xen Maintainance List <xen-maint> | ||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 5.3 | CC: | clalance, drjones, fajar, riek, xen-maint | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Other | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2010-06-24 08:10:15 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 514491 | ||||||
Attachments: |
|
Description
John Levon
2009-04-23 14:56:07 UTC
There's a patch going into the 5.4 kernel that *may* address this issue; see https://bugzilla.redhat.com/show_bug.cgi?id=477005. Can you try booting the kernel at: http://people.redhat.com/dzickus/el5 And see if it makes a difference? Chris Lalancette # virsh dumpxml domu-220 <domain type='xen' id='14'> <name>domu-220</name> <uuid>5cc2cb8c-53f0-c687-3bad-078feeef00c9</uuid> <memory>1048576</memory> <currentMemory>1048576</currentMemory> <vcpu>1</vcpu> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>preserve</on_crash> <distro> <type>linux</type> <variant>rhel5</variant> </distro> <devices> <emulator>/usr/lib/xen/bin/qemu-dm</emulator> <interface type='bridge'> <mac address='00:16:3e:3e:d8:58'/> <source bridge='e1000g0'/> <script path='/usr/lib/xen/scripts/vif-vnic'/> <target dev='vif14.0'/> </interface> <serial type='pty'> <source path='/dev/pts/2'/> <target port='0'/> </serial> <console type='pty' tty='/dev/pts/2'> <source path='/dev/pts/2'/> <target port='0'/> </console> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='5900' autoport='yes' keymap='en-us'/> </devices> </domain> (I'd removed the empty CD device, but that didn't help). virt-install line: virt-install --hvm --os-type=linux --os-variant=rhel5 -r 1024 -m `~johnlev/bin/maca domu-220` -n domu-220 -f /dev/zvol/dsk/export/dom/domu-220-root --vnc -c /net/heaped/export/netimage/linux/CentOS-5.3-x86_64-bin-DVD.iso Chris, this is a royal pain for me to do, it seems very unlikely that it's the same issue... I found in xenstore: control = "" error = "" device = "" vbd = "" 768 = "" error = "19 xlvbd_add at /local/domain/0/backend/vbd/14/768" I'm attaching a xenstore trace. Of interest: DOM PID TX OP 14 0 0 XS_READ: /local/domain/0/backend/vbd/14/768/state -> 4 14 0 0 XS_READ: /local/domain/0/backend/vbd/14/768/sectors -> 20971520 14 0 0 XS_READ: /local/domain/0/backend/vbd/14/768/info -> 0 14 0 0 XS_READ: /local/domain/0/backend/vbd/14/768/sector-size -> 512 14 0 0 XS_WRITE: error/device/vbd/768/error 19 xlvbd_add at /local/domain/0/backend/vbd/14/768 -> OK 14 0 0 XS_READ: device/vbd/768/state -> 3 Created attachment 340953 [details]
xenstore trace
I'm told that full-PV install of RHEL5.3 works perfectly. (In reply to comment #3) > Chris, this is a royal pain for me to do, it seems very unlikely that it's the > same issue... I'm not sure why, on either count. If you can just boot without loading the PV-on-HVM drivers, install the updated kernel, and then boot again with the PV-on-HVM drivers, that should show it. Also, the call trace here looks very similar to the one in 477005; while that one was about our -debug variant, the fact remains that the debug code is pointing out a potential problem that could hit the non-debug variant. It still may be a different issue, but it should be a relatively easy test to see if it works with the updated kernels. Chris Lalancette Is there a boot option to disable the PV drivers then? Otherwise I have to learn how to access the disk from another Linux domU. I don't know much about LVM... Oops, that dumpxml is wrong. It should have: <disk type='block' device='disk'> <driver name='phy'/> <source dev='/dev/zvol/dsk/export/dom/domu-220-root'/> <target dev='hda' bus='ide'/> </disk> There. I changed this to: <disk type='block' device='disk'> <driver name='phy'/> <source dev='/dev/zvol/dsk/export/dom/domu-220-root'/> <target dev='xvda' bus='xen'/> </disk> and it booted: Setting up Logical Volume Management: Found duplicate PV Yj7apcCwwN5g7myctf7jTqggVFJt9f3x: using /dev/xvda2 not /dev/hda2 2 logical volume(s) in volume group "VolGroup00" now active [ OK ] Something must be going wrong in the device calculations? This is a post I made earlier to xen-discuss, reposted here as per John Levon's request ================================ I'm using RHEL5.3 x86_64 as dom0 and Centos 5.3 x86_64 HVM domU, with Xen 3.3.1. By default PV drivers are LOADED, but not USED. hda is still handled by ata_piix, and eth0 handled by 8139cp. xen-vbd is loaded, but it does not have any devices (because hda is already handled by ata_piix). xen-net is loaded and got eth1 with the same MAC address as eth0. During boot, you can see that xen-vbd tries to grab hda but cannot (I'll get to this later). This works fine in Linux, domU can continue to boot. To get domU to actually USE the PV drivers for hda and eth0, some steps are required : http://pastebin.com/fb6fe631 The point here is that on Linux dom0, whatever driver handles hda, domU can continue to work. Now here comes the funny part. In opensolaris dom0, the process of xen-vbd trying to grab hda actually cause KERNEL PANIC. So here's what I did to get it working on opensolaris dom0: - do a zvol-backed fresh-install of Centos 5.3 on opensolaris dom0. I got kernel-2.6.18-128.el5. It panics on the first reboot. - export the zvol with iscsi, mount on linux, move /lib/modules/2.6.18-128.el5/kernel/drivers/xenpv_hvm/blkfront/xen-vbd.ko out of the way (I simply rename it to xen-vbd.ko.disabled) - startup domU again on opensolaris - edit /etc/modprobe.conf, add "alias scsi_hostadapter2 xen-vbd". This will ensure xen-vbd is included on initrd later. - yum -y install kernel. I'll get kernel-2.6.18-128.1.6.el5, and during the installation process it also generates initrd-2.6.18-128.1.6.el5.img which contains xen-vbd.ko. - edit /boot/grub/menu.lst to look like this title CentOS (2.6.18-128.1.6.el5) root (hd0,0) kernel /boot/vmlinuz-2.6.18-128.1.6.el5 ro root=LABEL=/ ide0=noprobe initrd /boot/initrd-2.6.18-128.1.6.el5.img the part "ide0=noprobe" tells ata_piix (or is it libata?) to NOT probe hda and hdb. - reboot On the reboot process you can see that xen-vbd now handles hda. Note that hdc (the cdrom) is still handled by ide-cd. As a bonus, xen-net now handles eth0. [root@localhost ~]# ls -lad /sys/block/hd*/device /sys/block/hd*/device/driver/module /sys/class/net/eth*/device/driver/module lrwxrwxrwx 1 root root 0 May 8 03:57 /sys/block/hda/device -> ../../devices/xen/vbd-768 lrwxrwxrwx 1 root root 0 May 8 04:19 /sys/block/hda/device/driver/module -> ../../../../module/xen_vbd lrwxrwxrwx 1 root root 0 May 8 03:57 /sys/block/hdc/device -> ../../devices/pci0000:00/0000:00:01.1/ide1/1.0 lrwxrwxrwx 1 root root 0 May 8 04:19 /sys/block/hdc/device/driver/module -> ../../../../module/ide_cd lrwxrwxrwx 1 root root 0 May 8 04:17 /sys/class/net/eth0/device/driver/module -> ../../../../module/xen_vnif lrwxrwxrwx 1 root root 0 May 8 04:19 /sys/class/net/eth1/device/driver/module -> ../../../../module/8139cp John, Have you tried (and had better success) booting RHEL 5.4 or 5.5 on this platform? thanks, Andrew Sorry, I no longer have time or inclination to work on this issue. Thanks John. We'll close this out for now. It can always be reopened if necessary. Andrew Clearing out old flags for reporting purposes. Chris Lalancette |