vmware: support skipping DHCP in initramfs #518
Comments
Which issue are you referring to?
I think you are asking "is it possible to not request DHCP during the initramfs on firstboot?". Is that correct? Assuming that is the question you are asking part of the answer depends on what platform you are running on, but in general the answer is "yes" because you can remove the `ip=dhcp rd.neednet=1" from the kernel command line when you boot the machine. Also soon we will be doing some more intelligent checking and automatically not bring up the network in the initramfs on first boot if you don't need it. |
yes
Thanks for this! Yes the kernel boot parameters includes this: But I haven't found a sample how one can remove |
remoe
changed the title
|
The As I mentioned before all of this is going to change soon (with #460) so you won't need to do this, assuming your Ignition configuration doesn't need the network. |
|
Thanks, but i need it on first boot without manual editing, because I setup a bunch of VM's with terraform and one of this VM provide DNS and DHCP. This need to boot fast without hang on not existing DHCP. Can I test the latest changes with an official test release? |
A bunch of VMs - that's great!
Unfortunately the code is under review right now and hasn't landed in our development builds yet, but is expected to soon. It looks like from the original title of this issue you're using the OVA file for VMWare? I know how to crack open and edit a qcow2, but not the OVA. Here's how you would do it for the qcow2: |
|
Thanks, I found an interesting blog article about something similarly: https://www.openshift.com/blog/openshift-upi-using-static-ips. I try to modify the OVA. |
|
@remoe this is a work in progress at the moment. The logic is implemented in coreos/afterburn#404 but the OS plumbing part is still ongoing. I'll add some docs when this is readily available in FCOS, keep watching this space. |
lucab
changed the title
|
@lucab, thanks! Here is a hint for others to solve this issue temporary: wget https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200517.3.0/x86_64/fedora-coreos-31.20200517.3.0-vmware.x86_64.ova
sudo apt-get install qemu-utils
tar xfv fedora-coreos-31.20200517.3.0-vmware.x86_64.ova pkg
qemu-img convert -f vmdk -O raw pkg/disk.vmdk disk.raw
mkdir disk
sudo mount -o loop,offset=1048576 disk.raw disk
- edit disk/"ignition.firstboot": set ignition_network_kcmdline=``
qemu-img convert -f raw -O vmdk disk.raw pkg/disk.vmdk -o adapter_type=lsilogic,subformat=streamOptimized,compat6
ovftool --lax --sourceType=OVF --targetType=OVA pkg/coreos.ovf fedora-coreos-31.20200517.3.0-vmware-nodhcp.x86_64.ova |
|
and you're unblocked? |
|
Right in https://bugzilla.redhat.com/show_bug.cgi?id=1836248 we agreed to support this workflow. But to emphasize first Luca's response, we have a much better fix for this incoming for VSphere, and the Live ISO is a full scriptable tool for complex networking that applies across bare metal, VSphere etc. |
|
@dustymabe , yes it boot without DHCP requests. Great! |
|
Is it correct that 32.20200601.3.0 should support "guestinfo.afterburn.initrd.network-kargs" (coreos/afterburn@d4aa045) ? (because it use afterburn-4.4.0). So this should fix this issue? |
|
@remoe no, because coreos/fedora-coreos-config#458 has not reached the |
lucab
added
the
status/pending-stable-release
|
@lucab thanks, but I don't understand the "Release Date: 16 Jun, 2020". This date has nothing to do with image version name?
|
Correct (if you read some documentation that states otherwise, please let us know as it may need to be fixed). The second field in a release version is only to track when we snapshot the set of packages from Fedora. For stable, there is an almost guaranteed mismatch with the release date, due to the stabilization time and testing->stable promotion. This is covered with more details in https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#version-numbers. |
|
Hmm, maybe we should add a |
|
@remoe - were you able to test out the latest testing stream release? |
|
@dustymabe I've tried it today with following "vsphere_virtual_machine" parameters: fedora-coreos-32.20200615.2.1-vmware.x86_64.ova resource "vsphere_virtual_machine" "test-vm" {
...
vapp {
properties = {
"guestinfo.ignition.config.data.encoding" = "base64"
"guestinfo.ignition.config.data" = base64encode(data.ct_config.simple-vm.rendered)
"guestinfo.afterburn.initrd.network-kargs" = ""
}
}
}But this throws the following error: @lucab this should be work without any |
|
@remoe yes, it will work with anything which can set guestinfo properties. I think you are hitting a known limitation in Terraform, see https://www.terraform.io/docs/providers/vsphere/r/virtual_machine.html#using-vapp-properties-to-supply-ovf-ova-configuration. The template does not (and should not) be changed because that property is optional, it has already a distribution default and an empty value is a valid override (like in your case). You should check this with some Terraform expert (which I'm not), but I think some viable approaches to try are:
If any of the above works, it would be nice to note that down here. |
|
@lucab, properties = {
"guestinfo.ignition.config.data.encoding" = "base64"
"guestinfo.ignition.config.data" = base64encode(data.ct_config.simple-vm.rendered)
"guestinfo.afterburn.initrd.network-kargs" = ""
}After boot it has still "rd.neednet=1" in the boot cmdline (/proc/cmdline): BOOT_IMAGE=(hd0,gpt1)/ostree/fedora-coreos-d00b3bc7e6d2b2fecf92b37cbddf9d45284cea92b477234e37d32dd277083ab9/vmlinuz-5.6.18-300.fc32.x86_64 mitigations=auto,nosmt systemd.unified_cgroup_hierarchy=0 console=tty0 console=ttyS0,115200n8 ignition.firstboot rd.neednet=1 ostree=/ostree/boot.1/fedora-coreos/d00b3bc7e6d2b2fecf92b37cbddf9d45284cea92b477234e37d32dd277083ab9/0 ignition.platform.id=vmwareAnd it hang here:
|
For reference, how did you do that? Is the importing and setting flow automated as well?
Yes, that's expected. It is going to be tackled with #443 but Ignition needs to be enhanced first. For the moment you can only setup the static address directly via |
|
Another try:
vapp {
properties = {
"guestinfo.ignition.config.data.encoding" = "base64"
"guestinfo.ignition.config.data" = base64encode(data.ct_config.simple-vm.rendered)
"guestinfo.afterburn.initrd.network-kargs" = "ip=x.x.x.x"
}
}
no |
|
@remoe that's correct, you won't see it in the bootloader command-line, as it is applied later on. |
|
@lucab |
|
@remoe That seems to hint at the fact that the guestinfo is not properly set on the VM. Can you please first try the govc way (documentation PR is in flight here), so that we can find out where the issue is by excluding components? |
|
@lucab, thanks. This works: |
|
@lucab it is solved ;) It works with terraform with following parameters: vapp {
properties = {
"guestinfo.ignition.config.data.encoding" = "base64"
"guestinfo.ignition.config.data" = base64encode(data.ct_config.simple-vm.rendered)
}
}
extra_config = {
# https://www.man7.org/linux/man-pages/man7/dracut.cmdline.7.html
"guestinfo.afterburn.initrd.network-kargs" = "ip=x.x.x.x::x.x.x.x:255.255.255.224:mynode01:eth0:off"
}And the template is not needed to be changed! |
|
@remoe ack, that's very good feedback. So there seems to be some friction between terraform, vapp properties and guestinfo entries. I don't have a proper terraform setup at hand to play with right now, but I'll keep this on my radar. Thanks for experimenting with us! |
|
@lucab , thanks as well :) I'm happy to help. |
|
Thanks @remoe for helping confirm this. Since the fix is in testing stream release |
|
The OpenShift installer currently uses Terraform as a backend on some platforms, so this is also useful to prove out how IPI VSphere could make use of this for static IP addressing (if desired). Thanks for trying it out! |
|
The fix for this went into stable stream release |
dustymabe
removed
the
status/pending-stable-release
Is it currently really the case that when one define two static networks like:
FCOS Version: 31.20200505.3.0-vmware.x86_64
ETH0:
ETH1:
Then the NetworkManager do this at boot ?:
I know about the current issue with static networks. But I'm not sure if my configuration is correct. Is it currently possible to apply a workaround to avoid this DHCP requests?
The text was updated successfully, but these errors were encountered: