Hide Forgot
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.