[nova] Spawning instance that will do PXE booting
Hi, In order to test OCI [1] within OpenStack itself, I would need my instances to do PXE booting. This would be with something like this on the qemu command line: qemu-system-x86_64 -boot n I believe this would also mean setting-up network cards that can do PXE booting, like the e1000, which Qemu supports. If that is possible, then I would setup DHCP + tftp-hpa on another instance, wired on the same private network. Your thoughts? Is this possible? Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
Here is what I would do, not validated. * Create a network with DHCP disabled. * Launch a VM to support PXE boot. * Launch a VM on volume based on any image for PXE boot. * The default virtio nic works fine with PXE boot. * "virsh edit <instance>" to enable PXE boot on the compute node. * "soft reboot" VM should bring VM to PXE boot. I prefer to do this with virsh/libvirt directly, which is much easier. Tony ________________________________________ From: Thomas Goirand <zigo@debian.org> Sent: December 1, 2021 02:33 PM To: openstack-discuss@lists.openstack.org Subject: [nova] Spawning instance that will do PXE booting Hi, In order to test OCI [1] within OpenStack itself, I would need my instances to do PXE booting. This would be with something like this on the qemu command line: qemu-system-x86_64 -boot n I believe this would also mean setting-up network cards that can do PXE booting, like the e1000, which Qemu supports. If that is possible, then I would setup DHCP + tftp-hpa on another instance, wired on the same private network. Your thoughts? Is this possible? Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
Hi Tony, Thanks for your reply. On 12/2/21 12:47 AM, Tony Liu wrote:
Here is what I would do, not validated. * Create a network with DHCP disabled. * Launch a VM to support PXE boot. * Launch a VM on volume based on any image for PXE boot. * The default virtio nic works fine with PXE boot. * "virsh edit <instance>" to enable PXE boot on the compute node.
This isn't an option. To do "virsh edit", you need to have root access to a compute node, and that's not what I would like to do: I'd like my CI to run with a normal OpenStack account only, to make it easy for people to reuse.
* "soft reboot" VM should bring VM to PXE boot.
I prefer to do this with virsh/libvirt directly, which is much easier.
Tony
Cheers, Thomas Goirand (zigo)
On Wed, Dec 1, 2021, at 2:33 PM, Thomas Goirand wrote:
Hi,
In order to test OCI [1] within OpenStack itself, I would need my instances to do PXE booting. This would be with something like this on the qemu command line:
qemu-system-x86_64 -boot n
I believe this would also mean setting-up network cards that can do PXE booting, like the e1000, which Qemu supports.
If that is possible, then I would setup DHCP + tftp-hpa on another instance, wired on the same private network.
Your thoughts? Is this possible?
I'm not super familiar with all the details but I believe ironic does something similar in their devstack plugin [2]. They do this so they can create fake baremetal instances that are actually VMs that ironic manages. But a similar setup will probably work for your use cases if PXE is what you are starting with.
Cheers,
Thomas Goirand (zigo)
[1] https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
[2] https://opendev.org/openstack/ironic/src/branch/master/devstack/lib/ironic#L...
On 12/2/21 12:51 AM, Clark Boylan wrote:
I'm not super familiar with all the details but I believe ironic does something similar in their devstack plugin [2]. They do this so they can create fake baremetal instances that are actually VMs that ironic manages. But a similar setup will probably work for your use cases if PXE is what you are starting with.
[2] https://opendev.org/openstack/ironic/src/branch/master/devstack/lib/ironic#L...
Hi, Thanks Clark for your answer. I've read the script a little bit, and I have to admit I do not understand what it does... :( If some Ironic falks can explain, that'd be great! Cheers, Thomas Goirand (zigo)
On Thu, Dec 2, 2021 at 12:10 AM Thomas Goirand <zigo@debian.org> wrote:
On 12/2/21 12:51 AM, Clark Boylan wrote:
I'm not super familiar with all the details but I believe ironic does something similar in their devstack plugin [2]. They do this so they can create fake baremetal instances that are actually VMs that ironic manages. But a similar setup will probably work for your use cases if PXE is what you are starting with.
[2] https://opendev.org/openstack/ironic/src/branch/master/devstack/lib/ironic#L...
Hi,
Thanks Clark for your answer.
I've read the script a little bit, and I have to admit I do not understand what it does... :(
If some Ironic falks can explain, that'd be great!
Cheers,
Thomas Goirand (zigo)
Extreme magic - OpenStack Edition. At least that feels like the answer. In essence, we create VMs. We attach them to the network, then configure virtualbmc or sushy-tools to play the role of a BMC and one of the things that library understand is the giant switch of "boot to network". From there we ipxe boot. The VMs play the role of baremetal machines through the emulation of the BMC and they are just hooked up to the network. This does require the job to use root privileges to setup networking/vms. And the virtualbmc or sushy-tools service needs enough rights to toggle the VM's config. Would be happy to try and discuss specifics of the devstack plugin, but I'm unsure if that would really help. Regardless, you know where to find us. :) As an aside, when I first read the post I was thinking of booting from ISO images. I've known people to embed ipxe into disk images, and you can embed static config/instructions for booting into an ipxe binary. It does require custom binary builds, but it might make what you're trying to achieve easier.
On 12/3/21 10:41 PM, Julia Kreger wrote:
Extreme magic - OpenStack Edition. At least that feels like the answer.
In essence, we create VMs. We attach them to the network, then configure virtualbmc or sushy-tools to play the role of a BMC and one of the things that library understand is the giant switch of "boot to network". From there we ipxe boot. The VMs play the role of baremetal machines through the emulation of the BMC and they are just hooked up to the network.
This does require the job to use root privileges to setup networking/vms. And the virtualbmc or sushy-tools service needs enough rights to toggle the VM's config. Would be happy to try and discuss specifics of the devstack plugin, but I'm unsure if that would really help. Regardless, you know where to find us. :)
As an aside, when I first read the post I was thinking of booting from ISO images. I've known people to embed ipxe into disk images, and you can embed static config/instructions for booting into an ipxe binary. It does require custom binary builds, but it might make what you're trying to achieve easier.
Hi Julia! Thanks for your answer. Well, I've read multiple times your reply, but I have to admit I still don't get all the details. For example, how would you "embed ipxe into disk images" for example? Should I for example run the iPXE binary from something like syslinux (or grub?)? But isn't iPXE usually running *after* the BIOS of a PC gets an IP from DHCP? I've just read a post where someone boots the iPXE binary from Grub, so that part shouldn't be hard: format a disk, make a ext4 partition, put the iPXE binary there, and tell grub to execute it. Is that all?!? Cheers, Thomas Goirand (zigo) P.S: I do have some knowledge on how to prepare disk images. After all, I've maintained the Debian OpenStack images for 3 Debian releases. So I probably just need a few pointers...
On Fri, Dec 3, 2021 at 3:22 PM Thomas Goirand <zigo@debian.org> wrote:
On 12/3/21 10:41 PM, Julia Kreger wrote:
Extreme magic - OpenStack Edition. At least that feels like the answer.
In essence, we create VMs. We attach them to the network, then configure virtualbmc or sushy-tools to play the role of a BMC and one of the things that library understand is the giant switch of "boot to network". From there we ipxe boot. The VMs play the role of baremetal machines through the emulation of the BMC and they are just hooked up to the network.
This does require the job to use root privileges to setup networking/vms. And the virtualbmc or sushy-tools service needs enough rights to toggle the VM's config. Would be happy to try and discuss specifics of the devstack plugin, but I'm unsure if that would really help. Regardless, you know where to find us. :)
As an aside, when I first read the post I was thinking of booting from ISO images. I've known people to embed ipxe into disk images, and you can embed static config/instructions for booting into an ipxe binary. It does require custom binary builds, but it might make what you're trying to achieve easier.
Hi Julia!
Thanks for your answer.
Well, I've read multiple times your reply, but I have to admit I still don't get all the details. For example, how would you "embed ipxe into disk images" for example? Should I for example run the iPXE binary from something like syslinux (or grub?)? But isn't iPXE usually running *after* the BIOS of a PC gets an IP from DHCP?
I'm sure there are other examples around but the one we used to (maybe still do) use for ovb can be built via: https://opendev.org/openstack/openstack-virtual-baremetal/src/branch/master/... You basically build an image that just attempts ipxe on repeat. $ git clone --recurse-submodules --remote-submodules https://opendev.org/openstack/openstack-virtual-baremetal $ cd openstack-virtual-baremetal/ipxe $ make ??? $ openstack image create --file ipxe-boot.img ipxe-boot
I've just read a post where someone boots the iPXE binary from Grub, so that part shouldn't be hard: format a disk, make a ext4 partition, put the iPXE binary there, and tell grub to execute it. Is that all?!?
Cheers,
Thomas Goirand (zigo)
P.S: I do have some knowledge on how to prepare disk images. After all, I've maintained the Debian OpenStack images for 3 Debian releases. So I probably just need a few pointers...
On 12/3/21 11:34 PM, Alex Schultz wrote:
On Fri, Dec 3, 2021 at 3:22 PM Thomas Goirand <zigo@debian.org> wrote:
On 12/3/21 10:41 PM, Julia Kreger wrote:
Extreme magic - OpenStack Edition. At least that feels like the answer.
In essence, we create VMs. We attach them to the network, then configure virtualbmc or sushy-tools to play the role of a BMC and one of the things that library understand is the giant switch of "boot to network". From there we ipxe boot. The VMs play the role of baremetal machines through the emulation of the BMC and they are just hooked up to the network.
This does require the job to use root privileges to setup networking/vms. And the virtualbmc or sushy-tools service needs enough rights to toggle the VM's config. Would be happy to try and discuss specifics of the devstack plugin, but I'm unsure if that would really help. Regardless, you know where to find us. :)
As an aside, when I first read the post I was thinking of booting from ISO images. I've known people to embed ipxe into disk images, and you can embed static config/instructions for booting into an ipxe binary. It does require custom binary builds, but it might make what you're trying to achieve easier.
Hi Julia!
Thanks for your answer.
Well, I've read multiple times your reply, but I have to admit I still don't get all the details. For example, how would you "embed ipxe into disk images" for example? Should I for example run the iPXE binary from something like syslinux (or grub?)? But isn't iPXE usually running *after* the BIOS of a PC gets an IP from DHCP?
I'm sure there are other examples around but the one we used to (maybe still do) use for ovb can be built via:
https://opendev.org/openstack/openstack-virtual-baremetal/src/branch/master/...
You basically build an image that just attempts ipxe on repeat.
Hi Alex! In fact, I just found out my solution: http://boot.ipxe.org/ipxe.iso Just download this, then: openstack image create \ --disk-format iso \ --container-format bare \ --file ipxe.iso ipxe.iso Et voila! The VM boots from PXE (I checked on the VNC console, and it also gets DHCP). I didn't go further, but it should be easy to setup the rest of the components (ie: a private network without DHCP, and a VM acting as DHCPd + tftp-hpa). I'll let you guys know how much progress I'm making with all of this (probably I'll start working on this next week...). Cheers, Thomas Goirand (zigo)
On Fri, Dec 3, 2021 at 3:45 PM Thomas Goirand <zigo@debian.org> wrote:
On 12/3/21 11:34 PM, Alex Schultz wrote:
On Fri, Dec 3, 2021 at 3:22 PM Thomas Goirand <zigo@debian.org> wrote:
On 12/3/21 10:41 PM, Julia Kreger wrote:
Extreme magic - OpenStack Edition. At least that feels like the answer.
In essence, we create VMs. We attach them to the network, then configure virtualbmc or sushy-tools to play the role of a BMC and one of the things that library understand is the giant switch of "boot to network". From there we ipxe boot. The VMs play the role of baremetal machines through the emulation of the BMC and they are just hooked up to the network.
This does require the job to use root privileges to setup networking/vms. And the virtualbmc or sushy-tools service needs enough rights to toggle the VM's config. Would be happy to try and discuss specifics of the devstack plugin, but I'm unsure if that would really help. Regardless, you know where to find us. :)
As an aside, when I first read the post I was thinking of booting from ISO images. I've known people to embed ipxe into disk images, and you can embed static config/instructions for booting into an ipxe binary. It does require custom binary builds, but it might make what you're trying to achieve easier.
Hi Julia!
Thanks for your answer.
Well, I've read multiple times your reply, but I have to admit I still don't get all the details. For example, how would you "embed ipxe into disk images" for example? Should I for example run the iPXE binary from something like syslinux (or grub?)? But isn't iPXE usually running *after* the BIOS of a PC gets an IP from DHCP?
I'm sure there are other examples around but the one we used to (maybe still do) use for ovb can be built via:
https://opendev.org/openstack/openstack-virtual-baremetal/src/branch/master/...
You basically build an image that just attempts ipxe on repeat.
Hi Alex!
In fact, I just found out my solution: http://boot.ipxe.org/ipxe.iso
Yea I think that's what gets built with make and then it qemu-img converts it for you.
Just download this, then:
openstack image create \ --disk-format iso \ --container-format bare \ --file ipxe.iso ipxe.iso
Et voila! The VM boots from PXE (I checked on the VNC console, and it also gets DHCP). I didn't go further, but it should be easy to setup the rest of the components (ie: a private network without DHCP, and a VM acting as DHCPd + tftp-hpa).
Yea as previously mentioned you may just need to disable port security and it should be fine. This is basically what we (tripleo) do in our 3rd party testing where the dhcpd is from the undercloud. I've also used the same image locally in libvirt + sushy-emulator for testing as well.
I'll let you guys know how much progress I'm making with all of this (probably I'll start working on this next week...).
Cheers,
Thomas Goirand (zigo)
On Fri, Dec 3, 2021 at 3:45 PM Thomas Goirand <zigo@debian.org> wrote:
On 12/3/21 11:34 PM, Alex Schultz wrote:
On Fri, Dec 3, 2021 at 3:22 PM Thomas Goirand <zigo@debian.org> wrote:
On 12/3/21 10:41 PM, Julia Kreger wrote:
Extreme magic - OpenStack Edition. At least that feels like the answer.
In essence, we create VMs. We attach them to the network, then configure virtualbmc or sushy-tools to play the role of a BMC and one of the things that library understand is the giant switch of "boot to network". From there we ipxe boot. The VMs play the role of baremetal machines through the emulation of the BMC and they are just hooked up to the network.
This does require the job to use root privileges to setup networking/vms. And the virtualbmc or sushy-tools service needs enough rights to toggle the VM's config. Would be happy to try and discuss specifics of the devstack plugin, but I'm unsure if that would really help. Regardless, you know where to find us. :)
As an aside, when I first read the post I was thinking of booting from ISO images. I've known people to embed ipxe into disk images, and you can embed static config/instructions for booting into an ipxe binary. It does require custom binary builds, but it might make what you're trying to achieve easier.
Hi Julia!
Thanks for your answer.
Well, I've read multiple times your reply, but I have to admit I still don't get all the details. For example, how would you "embed ipxe into disk images" for example? Should I for example run the iPXE binary from something like syslinux (or grub?)? But isn't iPXE usually running *after* the BIOS of a PC gets an IP from DHCP?
I'm sure there are other examples around but the one we used to (maybe still do) use for ovb can be built via:
https://opendev.org/openstack/openstack-virtual-baremetal/src/branch/master/...
You basically build an image that just attempts ipxe on repeat.
Hi Alex!
In fact, I just found out my solution: http://boot.ipxe.org/ipxe.iso
Yea I think that's what gets built with make and then it qemu-img converts it for you.
Just download this, then:
openstack image create \ --disk-format iso \ --container-format bare \ --file ipxe.iso ipxe.iso
Et voila! The VM boots from PXE (I checked on the VNC console, and it also gets DHCP). I didn't go further, but it should be easy to setup the rest of the components (ie: a private network without DHCP, and a VM acting as DHCPd + tftp-hpa).
Yea as previously mentioned you may just need to disable port security and it should be fine. This is basically what we (tripleo) do in our 3rd party testing where the dhcpd is from the undercloud. I've also used the same image locally in libvirt + sushy-emulator for testing as well. disabling port security might help but in general pxe booting nova instance is not supported. as in this is intentally not a supproted usecase currently, not that it coudl not be enable but we dont intend it to work outside of a ironic context. disbaling port security really shoudl only be required if you want to run your own dhcp server, if you willing ot manually
On Fri, 2021-12-03 at 15:54 -0700, Alex Schultz wrote: pxe boot interactivly you have ohter options. we also dont expclitly block pxe booting if the qemu seabios/uefi firmware support it so you can enable the boot menu vai hw:boot_menu=True extra spec or hw_boot_menu=True image property https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt... and select pxe boot if the firmware on the host loaded by qemu support it, but nova makes no guarentee that it will work with the libvirt driver. ironic is sort of a special case with regards to allowing/using pxe booting when its operating as a nova virt driver. in ironics case it more that nova does not care how the ironic servcei interally boots the instance and ironci just happens to use ipmi and pxe/ipxe as one of the options. you do not nesssiasarly need to use an ipxe boot image to pxeboot either as the seabios image, depening on your host useually has pxe supprot built in. your milage will vary however as this is outside the bounds of what is intended to work so if you encounterd issues adressing those would be new feature blueprint not bugs so they would not be backportable. if your intent is to just use this for testing then following in the path of tripleo and ironic by using virtualbmc to provide ipmi access to the vm might be ok but that assuems you are deploying an openstack cloud which you can then ssh into the hosts to install an run the virtual bmc. if you really want to do this in an unaltered cloud we would nee to configre the vm to boot form the network https://libvirt.org/formatdomain.html#bios-bootloader https://libvirt.org/formatdomain.html#specifying-boot-order im not sure what the best way to extend nova to support that would be, likely a neutron extention to mark ports a bootable which nova would read and then use to update the xml. host config is not really an option as it would be problematic for move operations, but flavor extra specs or image properites would be viable alternitive to the neutron approch. although neutorn ports would give a better ux. if you dont make progress with other approchs then you should consider fileing a spec for network boot support in nova/neutron.
I'll let you guys know how much progress I'm making with all of this (probably I'll start working on this next week...).
Cheers,
Thomas Goirand (zigo)
Hi Sean, Thanks a lot for all of your valuable info. On 12/6/21 9:15 AM, Sean Mooney wrote:
disbaling port security really shoudl only be required if you want to run your own dhcp server
This really is what I would like to do indeed.
you do not nesssiasarly need to use an ipxe boot image to pxeboot either as the seabios image, depening on your host useually has pxe supprot built in.
Right, but by default, OpenStack will not do "-boot n" to make the BIOS do PXE. So booting the ipxe.iso image is what I found as the most easy way. Is there another way?
your milage will vary however as this is outside the bounds of what is intended to work so if you encounterd issues adressing those would be new feature blueprint not bugs so they would not be backportable.
Well, my only concern is if I must disable port security (because this needs admin credentials), though it should be possible to workaround this using "opensack port set --allowed-address" as a non-admin.
if your intent is to just use this for testing then following in the path of tripleo and ironic by using virtualbmc to provide ipmi access to the vm might be ok but that assuems you are deploying an openstack cloud which you can then ssh into the hosts to install an run the virtual bmc.
Instead of the virtual BMC which I didn't like much, I currently use ipmi_sim from openipmi. This feels the right choice. Maybe supporting it would be a nice addition to OpenStack.
if you really want to do this in an unaltered cloud we would nee to configre the vm to boot form the network https://libvirt.org/formatdomain.html#bios-bootloader https://libvirt.org/formatdomain.html#specifying-boot-order
im not sure what the best way to extend nova to support that would be, likely a neutron extention to mark ports a bootable which nova would read and then use to update the xml. host config is not really an option as it would be problematic for move operations, but flavor extra specs or image properites would be viable alternitive to the neutron approch. although neutorn ports would give a better ux. if you dont make progress with other approchs then you should consider fileing a spec for network boot support in nova/neutron.
Ok, thanks for your advice. I'll try first with the ipxe.iso image, as this looks like the most easy path for the moment, and I'll see if later on I need more. Cheers, Thomas Goirand (zigo)
We faced the same use case, and we end up doing something like this: - disable security on the network provider (or on the instance port where pxe boot is needed) - deploy or rescue the intance with an ipxe image Cheers On Wed, Dec 1, 2021, 23:36 Thomas Goirand <zigo@debian.org> wrote:
Hi,
In order to test OCI [1] within OpenStack itself, I would need my instances to do PXE booting. This would be with something like this on the qemu command line:
qemu-system-x86_64 -boot n
I believe this would also mean setting-up network cards that can do PXE booting, like the e1000, which Qemu supports.
If that is possible, then I would setup DHCP + tftp-hpa on another instance, wired on the same private network.
Your thoughts? Is this possible?
Cheers,
Thomas Goirand (zigo)
[1] https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
Hey all, On 01/12/2021 23:33, Thomas Goirand wrote:
In order to test OCI [1] within OpenStack itself, I would need my instances to do PXE booting. This would be with something like this on the qemu command line:
qemu-system-x86_64 -boot n
I believe this would also mean setting-up network cards that can do PXE booting, like the e1000, which Qemu supports.
If that is possible, then I would setup DHCP + tftp-hpa on another instance, wired on the same private network.
On 03/12/2021 21:01, Cedric Lemarchand wrote:
We faced the same use case, and we end up doing something like this:
- disable security on the network provider (or on the instance port where pxe boot is needed) - deploy or rescue the intance with an ipxe image
I ran into this exact issue in the past, searching for possibilities to boot Nova instances using PXE. Certainly the actual boot server should not be provided by Nova in any way - it's more about getting a VM to network boot. Actually the only change required would be to enable netboot via the boot order: * https://libvirt.org/formatdomain.html#specifying-boot-order There also have been blueprints or implementation attempts for nova before: * https://blueprints.launchpad.net/nova/+spec/boot-order-for-instance * https://review.opendev.org/c/openstack/nova-specs/+/133254/ Maybe if someone from the Nova devs would give an indication if supporting network boot would be worth discussing? The most basic use-case certainly are staging environments for physical (server) systems that do network boot. But I believe there likely are more ideas others could contribute. Christian
On 03/12/2021 21:01, Cedric Lemarchand wrote:
We faced the same use case, and we end up doing something like this:
- disable security on the network provider (or on the instance port where pxe boot is needed) - deploy or rescue the intance with an ipxe image
As for DHCP, you can very much use the OpenStack DHCP and just set the options like next-server / server-ip-address * https://docs.openstack.org/api-ref/network/v2/?expanded=update-port-detail#e... * https://docs.openstack.org/neutron/latest/ovn/dhcp_opts.html and this IP then points to your VM with the TFTP and other PXE / iPXE tooling running. Regards Christian
Thanks for the heads up. Pointer is about ovn, I didnt find anything regarding ovs. Did the Neutron API support these options both for ovn and ovs ? On Wed, Dec 8, 2021, 17:12 Christian Rohmann <christian.rohmann@inovex.de> wrote:
On 03/12/2021 21:01, Cedric Lemarchand wrote:
We faced the same use case, and we end up doing something like this:
- disable security on the network provider (or on the instance port where pxe boot is needed) - deploy or rescue the intance with an ipxe image
As for DHCP, you can very much use the OpenStack DHCP and just set the options like next-server / server-ip-address
*
https://docs.openstack.org/api-ref/network/v2/?expanded=update-port-detail#e... * https://docs.openstack.org/neutron/latest/ovn/dhcp_opts.html
and this IP then points to your VM with the TFTP and other PXE / iPXE tooling running.
Regards
Christian
So I validated what from my point of view seems to be the most "supported" way to boot an Openstack instance in PXE : - add the flavor the extra specs "hw:boot_menu = 1" (thanks Sean) - spawn the instance - configure the extra_dhcp_opts of the associated port (thanks Christian). Its not supported with the CLI, but doable with an sdk, below a Pythonic example [1] - reboot the instance, hit esc at the bios prompt then third choice (iPXE) This allows the use of the Openstack DHCP and to keep port security enabled, which is nice. Cheers [1] --- conn.update_port(port_id, extra_dhcp_opts=[ {"opt_name": "server-ip-address","opt_value": "10.0.0.15"}, {"opt_name": "bootfile-name", "opt_value": "pxelinux.0"}, {"opt_name": "tftp-server", "opt_value": "10.0.0.15"} ] ) --- On Wed, Dec 8, 2021 at 8:52 PM Cedric Lemarchand <yipikai7@gmail.com> wrote:
Thanks for the heads up.
Pointer is about ovn, I didnt find anything regarding ovs.
Did the Neutron API support these options both for ovn and ovs ?
On Wed, Dec 8, 2021, 17:12 Christian Rohmann <christian.rohmann@inovex.de> wrote:
On 03/12/2021 21:01, Cedric Lemarchand wrote:
We faced the same use case, and we end up doing something like this:
- disable security on the network provider (or on the instance port where pxe boot is needed) - deploy or rescue the intance with an ipxe image
As for DHCP, you can very much use the OpenStack DHCP and just set the options like next-server / server-ip-address
* https://docs.openstack.org/api-ref/network/v2/?expanded=update-port-detail#e... * https://docs.openstack.org/neutron/latest/ovn/dhcp_opts.html
and this IP then points to your VM with the TFTP and other PXE / iPXE tooling running.
Regards
Christian
On 12/12/21 6:38 PM, Cedric Lemarchand wrote:
So I validated what from my point of view seems to be the most "supported" way to boot an Openstack instance in PXE :
- add the flavor the extra specs "hw:boot_menu = 1" (thanks Sean) - spawn the instance - configure the extra_dhcp_opts of the associated port (thanks Christian). Its not supported with the CLI, but doable with an sdk, below a Pythonic example [1] - reboot the instance, hit esc at the bios prompt then third choice (iPXE)
This allows the use of the Openstack DHCP and to keep port security enabled, which is nice.
Cheers
[1] --- conn.update_port(port_id, extra_dhcp_opts=[ {"opt_name": "server-ip-address","opt_value": "10.0.0.15"}, {"opt_name": "bootfile-name", "opt_value": "pxelinux.0"}, {"opt_name": "tftp-server", "opt_value": "10.0.0.15"} ] )
Hi, It really is supported by the cli. I've done this way: openstack port create ${MACHINE} --network oci-boot-network \ --extra-dhcp-option \ name=tftp-server,value=$<ip>,ip-version=4 \ --extra-dhcp-option \ name=bootfile-name,value=http://<ip>/oci/ipxe.php,ip-version=4 \ --fixed-ip subnet=subname,ip-address=<fixed-ip> At the present moment, I have a working OCI [1] functional CI that works with non-admin OpenStack credentials (just a normal user). I hope to be able to share this very soon, so that anyone can try without too much hassle. Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
participants (8)
-
Alex Schultz
-
Cedric Lemarchand
-
Christian Rohmann
-
Clark Boylan
-
Julia Kreger
-
Sean Mooney
-
Thomas Goirand
-
Tony Liu