Nathan Johnson Senior R&D Engineer Education Networks of America
> On Mar 14, 2019, at 9:14 AM, Wido den Hollander <w...@widodh.nl> wrote: > > > > On 3/13/19 3:29 PM, Nathan Johnson wrote: >> I've put together an approach for EFI support that we would like to get some >> feedback on before I create a PR. Constructive criticism would be >> appreciated. >> >> I've added the following properties to be configured in the agent.properties: >> >> guest.loader.efi - boolean to switch efi on. This must be true before it >> will inject any <loader> entries into the domain xml >> guest.loader.image - this would be the path to the bios/efi image >> guest.loader.nvram - this optionally points to an nvram image >> >> >> Even when a host is configured so that it can use EFI, it will only actually >> create a virtual machine when both of the following conditions are met: >> >> 1) the host has guest.locader.efi set to true in its agent.properties > > Can't we detect if the host is EFI capable without the need of adding a > new flag to the agent.properties? There is no way that I'm aware of. libvirt expects its EFI configuration to come from the domain xml. > > It advertises the capability of EFI to the Mgmt server and only then can > efi=true Instances be started on that host. > >> 2) the vm has the vm details parameter efi=true >>> At present there is no automatic way for the management server to know > in advance which hosts have EFI enabled. I suppose this could be > approximated using tags. It might be nice to make this more automatic, > and have the resource planner aware of the efi toggle on the VM, but I'm > not sure how best to implement that or if it's even worth it. >> > > As others already mentioned. The Agent/Host capabilities should be > sufficient? Technically any host with a sufficiently new version of qemu can support efi, but again the domain xml has to be modified so that it points to the EFI firmware image location on disk. There really is no "host" level configuration, it's really per-domain.
smime.p7s
Description: S/MIME cryptographic signature
