Red Hat Bugzilla – Bug 488879
[DELL 6.0 FEAT] Update QEMU to use gPXE roms for iSCSI boot support
Last modified: 2013-01-09 16:28:52 EST
Cloning into RHEL 6. This belongs on package qemu, but as that isn't available in the bugzilla package list for RHEL6 yet, nor is kvm, it'll have to go here for now...
+++ This bug was initially created as a clone of Bug #457979 +++
Description of problem:
To enable guests to directly boot from an iSCSI target, without libvirt one can manually start qemu-kvm with the added command line parameter:
where the .rom file came from the gPXE (etherboot) project, and provides an iSCSI initiator as an option ROM. qemu then uses this option rom to retrieve the grub boot sectors, and it's off to the races.
libvirt needs the capability of passing such extra command line parameters to qemu.
Version-Release number of selected component (if applicable):
--- Additional comment from firstname.lastname@example.org on 2008-08-06 05:55:40 EDT ---
QEMU already automatically loads option ROMs for PXE boot - any reason why the updated ROM with iSCSI support can't just be integrated into QEMU so we don't have to specify a -option-rom explicitly.
Having users of libvirt need to know about loading option ROMs for booting isn't really going to lead to a good experiance. Most applications using libvirt will never even think to enable the option ROM support, even if we have it. Making it 'just work' in upstream QEMU will ensure all applications using libvirt can use the capability without needing special args.
--- Additional comment from email@example.com on 2008-08-06 08:20:22 EDT ---
I'd be happy for qemu to start using the gPXE option ROMs directly for this capability. But I also suspect there may be good reasons to want to pass other command line options to qemu from libvirt in the future, so having a general method to pass such options would be beneficial, even if the specific need for -option-rom isn't needed for long.
--- Additional comment from firstname.lastname@example.org on 2008-08-06 10:09:59 EDT ---
I've spoken with upstream KVM/QEMU maintainers and they would like to switch QEMU to using gPXE option ROMS by default, so I don't want to add any option ROM support into libvirt at this time. Re-assigning this bug component to track gPXE in KVM/QEMU
NB, we also explicitly do NOT enable passing of arbitrary QEMU command line args in libvirt. The libvirt XML format needs to be hypervisor agnostic and thus requires that we come up with a standardized representation for any piece of functionality. Allowing QEMU command line args would violate this requirement.
--- Additional comment from email@example.com on 2008-08-06 11:14:25 EDT ---
that works for me.
Charles -- Please update us with the upstream status of this request.
IBM is also interested in seeing the feature in RHEL 6
------- Comment From firstname.lastname@example.org 2009-08-18 14:58 EDT-------
1. Feature Overview:
Feature Id: 
a. Name of Feature: Switch qemu to use gpxe option rom for netboot
b. Feature Description
Switch qemu over to using gpxe option rom for network booting
2. Feature Details:
Arch Specificity: Both
Affects Kernel Modules: Yes
Delivery Mechanism: Backport
Request Type: Driver - Feature from Upstream
d. Upstream Acceptance: In Progress
Sponsor Priority 2
f. Severity: Medium
IBM Confidential: no
Code Contribution: IBM code
g. Component Version Target: gPXE 0.97 or newer, gemu-0.12 or newer
3. Business Case
IBM has a number of products that require a richer netweork booting environment. Tivoli Provision manager has a program that makes extensive use of PXE UNDI mode which has much better support in gPXE than the current etherboot module. Additionally, gPXE also includes iSCSI booting support which is a key diskless technology that IBM employs in bare-metal scenarios. Adding gPXE allows virtualization to fit more seamlessly into existing customer environments.
4. Primary contact at Red Hat:
5. Primary contacts at Partner:
Project Management Contact:
Stephanie Glass, email@example.com, 512-838-9284
Ryan Arnold, firstname.lastname@example.org
Warren Grunbok II, email@example.com
Reassigning to KVM as was initially intended.
*** Bug 464589 has been marked as a duplicate of this bug. ***
qemu-kvm uses gpxe since the first RHEL-6 packages were out. marking as MODIFIED.
Test in qemu-kvm-0.12.1.2-2.38.el6.x86_64,kernel-2.6.32-19.el6.x86_64.
#rpm -qf /usr/share/qemu-kvm/pxe-virtio.bin
#ls -l /usr/share/qemu-kvm/pxe-virtio.bin
lrwxrwxrwx. 1 root root 22 Apr 19 17:11 /usr/share/qemu-kvm/pxe-virtio.bin -> ../gpxe/virtio-net.rom
Boot guest from network
1. /usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -no-kvm-pit-reinjection -startdate now -drive file=RHEL-Server-5.5-64-virtio.qcow2,media=disk,format=qcow2,if=virtio,boot=on,cache=off,index=0 -net nic,vlan=0,macaddr=10:1a:4a:10:20:40,model=e1000 -net tap,vlan=0,ifname=e1000_11_1,script=/etc/qemu-ifup -cpu qemu64,+sse2 -balloon none -vnc :10 -uuid `uuidgen` -monitor stdio -m 2G -smp 2 -boot n
Can boot and install the guest successfully.
Change the status to verified then close it according to Comment 12.
Doing root boot using iSCSI requires that the NIC option ROM gets the root path from a source -
Some of the methods are -
1) DHCP server ( option 17)
gpxe option rom being part of qemu-kvm is step 1) that has been accomplished but the testing done above does not seem to be accurate.
The test has to be performed in the following way -
1) Install OS on the remote iSCSI LUN. (This can be done normally as is done using physical servers)
2) Patch the DHCP server with the following option and restart it -
option root-path "iscsi:my.target.dns.name::::iqn.2007-08.name.dns.target.my:iscsiboot";
I don't think creating a local disk image is necessary.. as we are booting from the remote target
Steps too boot from iSCSI target
3) The gpxe option rom would obtain the IP + root-path info from the DHCP server.
4) Now that gpxe is already part of the qemu-kvm package booting with PXE option should provide the root path if the DHCP server is properly patched.
I can't setup my own DHCP server in (: so unable to test this..