Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
The HP Lefthand P4000 series Multi-site SAN is a clustered storage node solution allowing a storage node failure and/or a site failure with uninterrupted service to attached servers.
A requirement to this resilience is a Fail Over Manager (FOM) acting as a Quorum vote within the cluster of storage nodes.
HP only provide the Failover manager in the form of a Virtual Appliance for VMware ESX, VMware Player/Server and Microsoft Hyper V.
This FailOver Manager is 100% necessary to enable automatic failover of storage nodes, in the event of a failure.
Customers who do not use VMware or HyperV have no means of running the FailOver Manager.
When the FailOver manager is started on a KVM virtualized guest, the Failover manager guest kernel panics on bootup.
Version-Release number of selected component (if applicable):
HP StorageWorks P4000 Storage System SAN/iQ Management Software DVD Version 9.0 (BM480-11003)
https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=P4000SW
How reproducible:
every time
Steps to Reproduce:
On a Windows Machine (Windows 7 used during tests)
1. Install VMware Server 2.0.
2. Install <DVD drive letter>:\FailoverManager\FOM_non_esx\bin\setup.exe
3. Accept all defaults of installer
4. Copy flash0.vmdk and array0.vmdk from C:\Program Files\HP\P4000\HP P4000 Failover Manager\ to a RHEL 6.1 KVM hypervisor
On a RHEL 6.1 KVM Hypervisor
1. convert VMDK files
qemu-img convert /path/to/flash0.vmdk -O raw /var/lib/libvirt/images/flash0.raw
qemu.img convert /path/to/array0.vmdk -O raw /var/lib/libvirt/images/array0.raw
2. Create new KVM guest in Virt-manager with the following
Name: <insert name here>, select "Import existing disk image"
Provide the existing storage path: Select "flash0.raw"
OS Type: Linux
Version: Red Hat Enterprise Linux 5.4 or later
Memory: 1024MB
CPUs: 1
Tick the box to "customize configuration before install" then click finish
Select "Disk 1", Advanced Options, change drive bus from default to "USB" and click apply.
Add Hardware, Storage, Select "managed or other existing storage", click browse
Select array0.raw
change "Device Type" to "USB Disk"
Click "Begin Installation"
3. At "Welcome to SAN/iQ" boot, allow automatic boot. (approx 3 seconds)
Actual results:
KVM guest will kernel panic shortly after boot, with the following dump on screen.
target0/lun0/part9]
mount: special device /dev/scsi/host0/bus0/target0/lun0/part1 does not exist
umount: /boot: not mounted
/bin/stat: cannot stat `/dev/scsi/host0/bus0/target0/lun0/part5': No such file or directory
/bin/stat: cannot stat `/dev/scsi/host0/bus0/target0/lun0/part5': No such file or directory
Authoritative root/OS filesystem:[major/minor] is /dev/scsi/host0/bus0/target0/lun0/part5:[0x]
===== setting kernel root dev to 0x =====
/linuxrc: line 41: echo: write error: Invalid argument
VFS: Cannot open root device "<NULL>" or unknown-block(8,2)
Please append the correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,2)
Pid: 1, comm: swapper Not tainted 2.6.32.15 #1
Call Trace:
[<c102ed92>] ? panic+0x3e/0x118
[<c147bb79>] ? mount_block_root+0xd5/0x238
[<c147bd1f>] ? mount_root+0x43/0xa8
[<c147c90f>] ? initrd_load+0x1f7/0x2f0
[<c147be49>] ? prepare_namespace+0xc5/0x180
[<c147b917>] ? kernel_init+0x15b/0x174
[<c147b7bc>] ? kernel_init+0x0/0x174
[<c1003cc7>] ? kernel_thread_healper+0x7/0x18
Expected results:
Failover Manager should boot successfully to login prompt.
Additional info:
This is not a Red Hat specific support problem, this ticket is being raised as an impact to Red Hat customers who are using the HP Lefthand P4000 series SAN in a KVM or RHEV based environment where VMware is not used.
Have you opened a ticket with HP to get a KVM guest image? While you might succeed in getting the image to run under KVM, I wonder whether HP would support such usage.
As far as getting the image to run under KVM, the problem is that the contents of the image are unknown, although it's clear from what you've posted that it's running some Linux kernel. While it's possible to convert known guest OS images from one virt format to another, this one is a blackbox. Your best bet is to find out exactly what hardware VMware is presenting and then trying to replicate that hardware in your KVM configuration, but depending on what's in the guest image that task may be very easy or very hard. You can also try using the guestfish / virt-edit / virt-rescue tools to edit the image.
I asked around, and one thought was that it's likely you are hitting BZ 548723, so doing the conversion to raw using the VMware tools instead of qemu-img might get you past the immediate problem.
This isn't a libvirt bug, so I am closing it as such, but opening a ticket with support might help in engaging HP.