The title summarizes it all. I have a VM solution that involves LibVirt, QEmu, and KVM. PXE-boot over HTTP works, but doesn't work on HTTPS. There are no firewall problems, I've checked that already.

Everything is CentOS Linux.

Any ideas how to debug this? Googling doesn't lead me anywhere, just how to enable PXE-boot (which is done and works fine over HTTP).

  • It would be better if you show us relevant logs. Sep 16, 2021 at 11:53
  • Which version of Qemu are you using? Are you booting in pcbios or efi mode? Do you see any messages on screen when it fails?
    – NiKiZe
    Sep 16, 2021 at 15:11
  • If it works over HTTP but not HTTPS, then the issue sounds like it could be to do with firewalls (which you say you've checked - can another working server curl the HTTPS URL?), or with something like SSL. As @NiKiZe says, are there any error messages? My guess would be that the CA is self-signed and there are errors when retrieving the URL.
    – shearn89
    Sep 23, 2021 at 10:32

1 Answer 1


OK, this ended up being quite interesting. Let me share the solution.

We actually maintain our own iPXE package at my company. It's just a fork of https://github.com/ipxe/ipxe where we adjust come configurations (like enabling HTTPS in my case), add our own certificate authority, etc. But we didn't build all the targets in the iPXE Makefile, just a few.

According to the NIC driver Qemu-KVM uses, you can use one of the targets in the Makefile. In our case, the relevant part of our VM configuration file (what you get by running virsh edit) was:

<interface type='bridge'>  
  <mac address='12:34:56:12:34:56'/>  
  <source bridge='br0'/>  
  <model type='virtio'/>  
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>

It's that "virtio" that got us to identify the proper target in the Makefile: bin/1af41000.rom. This was already used by Qemu-KVM, but of course it wasn't using our own. We updated the symlink after building that target to refer to our own, and that was it.

This article helped us figure out how to deal with the NIC drivers part.

  • You should have provided the information about iPXE in your question, and when dealing with iPXE (and other things) Always include the actual error message. In the case of iPXE the error you got when trying to use https: proto would have shown you an ipxe.org url, which in turn more or less would have told you that the protocol was not enabled. ipxe.org/3c092003
    – NiKiZe
    Sep 16, 2021 at 16:54
  • @NiKiZe: That was not the case. The error message had a generic error code that was not useful.
    – OmarOthman
    Sep 18, 2021 at 12:29
  • If you say that, then what was the actual error message?
    – NiKiZe
    Sep 18, 2021 at 19:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .