How to PXE boot a virtualbox or QEMU/KVM box ?
-
I don’t recall there being a problem so long ago. At least you creating a problem with it. You described a problem and I had to fix it. That’s how reports work. Some may be more problematic to fix than others, but that’s just how it goes.
I believe you can replace the ipxe rom files your QEMU/KVM systems are using. If you know what files need to be replaced, directly, I can probably build them with the relevant information you need for you.
-
for what it’s worth, i’ve been able to network boot virtualbox VMs without modification. I believe i had to use the “Intel PRO/1000 MT Desktop” network adapter type in the VM setup
-
I’m actually using the Intel Pro/1000 MT Desktop NIC, I must also tell I’m using a already existing dhcp server (debian 8).
I managed to chainload iPXE with the following dhcpd configuration :
if exists user-class and option user-class = "iPXE" { if exists ipxe.multiboot { # multiboot is a feature not available in VirtualBox, and available in the iPXE provided by FOG. filename "http://192.168.0.21/fog/service/ipxe/boot.php"; } else { option bootfile-name "tftp://192.168.0.21/undionly.kpxe"; } } else { filename "undionly.kpxe"; }
I did not test the last case, for computers without iPXE, because I’m focusing on my VM.
After a boot of my VM, iPXE loads, chains with iPXE from py FOG server. I see a second execution of iPXE with more built in features. Then it fails with the following obscure message :
“Could not start download : Operation not supported (http://ipxe.org/3c092003)”
-
@De-Thegeek said:
“Could not start download : Operation not supported (http://ipxe.org/3c092003)”
I am not exactly sure if this is what you are looking for but take a look yourself. Follow that link and read the very last bulit point on that website. Maybe that helps.
-
I did that at first, but it does not give a clue about what’s going wrong in my case. Even the links to the source code.
EDIT : I’vread your answer too quickly. I’ll try to tweak my VM, but I’ll need some time. As I’m already able to chainload iPXE, maybe my issue is not longer in PXE itself but in my setup in dhcpd.conf.
Is it still necessary to use “next-server” to specify the source of boot.php ?
-
AFAIK the undionly.kpxe is hardcoded to load default.ipxe script from the TFTP server. Check out /tftpboot/default.ipxe on your FOG server and you’ll see where boot.php comes into play.
-
I think I should lookup more closely how Junkhacker did to use a VirtualBox VM.
I’m using the same NIC from the beginning, so I guess there is something else to tweak. I guess changing the ROM is overkill if someone manages to avoid that.
-
Intel PRO/1000 MT Desktop Adapter Type
Bridged Adapter
that’s all i needed to do -
Thank you
I’m already using these settings. so I should search elsewhere. As my fog has been rebuilt from scratch and I dit that a while ago, I probably did something nasty.
I have to mention I managed to run FOG 0.32 in a container, with a userspace NFS server. I did that again, maybe there is something wrong with the container.
I’ll rebuild a new FOG server in a fully virtualized environment and see what happens.
-
Just for the records: I do PXE boot qemu on my laptop to test FOG stuff all the time. No trouble!
$ sudo tunctl -t tap0 -u <username> $ sudo ifconfig tap0 x.x.x.x netmask 255.255.255.0 up $ qemu-img create -f qcow2 hdd.qcow2 10G $ qemu -m 512 -boot n -net nic,vlan=1 -net tap,vlan=1,ifname=tap0,script=/bin/true -hda hdd.qcow2
This is not a briged setup but all running on a virtual LAN only on that computer. So you’d have to configure tftp and dhcpd to properly serve on NIC tap0 and IP x.x.x.x
-
Marking this solved as I have done extended testing on virtualbox 5.0.0 and cannot find an issue, see here: https://forums.fogproject.org/topic/5884/client-boot-error-msg-error-0x040ee119
Please let us know if you cannot get it to work this way.