DealingWithiPXE: Difference between revisions
| Line 5: | Line 5: | ||
== Solution == | == Solution == | ||
Instead of downgrading to gPXE (the past pathetic workaround), there's a better way that consists in customizing the rom by embedding | Instead of downgrading to gPXE (the past pathetic workaround), there's a better way that consists in customizing the rom by embedding an iPXE script in it. The generic method to embed scripts is described [http://ipxe.org/embed here], and iPXE scripting is explained [http://ipxe.org/scripting here]. We needed a script that tries all the NICs, and we have found [https://gist.github.com/robinsmidsrod/3871687 this cool iPXE menu] on GitHubGist (it does a bit more than just trying all the NICs in turn, its default behaviour...). | ||
Here is the detailed recipe of the solution that we applied on our hypervisors : | |||
Revision as of 13:26, 21 October 2017
Problem
New hypervisors come with iPXE installed instead of gPXE. This is not a problem in itself since iPXE brings a lot of new interesting features compared to gPXE. But the virtio iPXE ROM that's provided by default doesn't behave as it should with VMs that have several NICs : it only tries to boot from the first found NIC and then it stops if the boot failed, instead of trying the other NICs. For us, it's a big problem since many VMs have two NICs : the first one is the public, and the second one is the private, and that's the one that will be used to pxe-boot.
Solution
Instead of downgrading to gPXE (the past pathetic workaround), there's a better way that consists in customizing the rom by embedding an iPXE script in it. The generic method to embed scripts is described here, and iPXE scripting is explained here. We needed a script that tries all the NICs, and we have found this cool iPXE menu on GitHubGist (it does a bit more than just trying all the NICs in turn, its default behaviour...).
Here is the detailed recipe of the solution that we applied on our hypervisors :