Boot order of libvirt machines
The fact that the guests are set to always boot from net is both a security problem, and a technical problem.
Lets say someone sets up a rouge dhcp server, and either by intent or pure ignorance ends up renstalling a server with the latest version of windows8...
The technical problem is that you will have trouble booting with two interfaces defined.
At the moment I'm trying to create a host with two interfaces, and after the install is completed I'm unable to boot.
The firs nic starts with pxe, and try localboot, which means that it just do a exit, and the next card tries to boot, but on that network there is no pxe configured. And there it hangs....
I see that this has been discussed eariler (http://projects.theforeman.org/issues/1532), and I've asked about it on #theforeman, and I understand why you have chosen to do it this way, but I think it creates a risk, and at least I see technical problems with it.
#1 Updated by Lukas Zapletal about 6 years ago
the fact that someone is able to setup bad DHCP server on a network is a severe security flaw by itself. Foreman is designed for safe networks (e.g. lab networks, virtual networks), but this does not mean you are prohibited from changing how your server boot up.
Foreman itself does not setup server BIOS/firmware boot settings, this is up to you to do this manually. If you have some specific remote firmware setup tools provided by vendors like HP, IBM or Dell, you can automate this. Foreman has a plugin called foreman_hooks which helps you to create script which can be called after a host is created or put into build mode. You can integrate with that.
We have some plans for Foreman Discovery plugins for BIOS/firmware upgrades, but this is rather long-term goal. Until then, this is up to you how you want to boot your production servers. You do not need to use PXE at all, there is another plugin called foreman_bootdisk which creates ISO/flash disk images for provisioning.
We are open for patches, if you feel like adding boot priority to VM tab for libvirt would help, feel free to add this. Also respecify, how you would solve this issue.
#2 Updated by Svein-Erik Lund about 6 years ago
I'm not talking about setting the boot order on physical hardware, I'm talking about setting the bootorder for a virtual machine created with foreman using the foreman-libvirt integration.
For me a patch like this
152c152 < :boot_order => %w[network hd], --- > :boot_order => %w[hd network], 189a190
in the file
app/models/compute_resources/foreman/model/libvirt.rbwould solve my problem, but I can see that this is undesirable in other situations.
#4 Updated by Svein-Erik Lund about 6 years ago
If the boot order is set to [hd network] the vm will fail to boot from disk, and continue to boot from network when a new machine is created. That's the way I've solved the problem for now.
That said I totally agree that this isn't an optimal solution, but at least I can boot my virtual machines..
The best solution imho would be to set the vm to boot from net when it's set to build, and to boot from disk when it's finished.
A simpler solution would be to add an option to the UI to set the boot order of the vm
I would love to be able to help change this, but my programming skills are limited to python (and that's limited to...).
If there is any other way I can help I'll gladly do it :)