mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
OSDOCS-17013-bm-upi-2: Continuation of the CQA2 for installing-bare-metal.adoc
This commit is contained in:
dfitzmau
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
ad587daa9d
commit
401bd236bf
@@ -1,3 +1,7 @@
|
||||
ifeval::["{context}" == "installing-with-agent-based-installer"]
|
||||
:agent:
|
||||
endif::[]
|
||||
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="installing-bare-metal-network-customizations"]
|
||||
= Installing a user-provisioned bare metal cluster with network customizations
|
||||
@@ -152,6 +156,20 @@ include::modules/installation-user-infra-machines-pxe.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-network.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-disk.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-retain-disk.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-ignition.adoc[leveloffset=+3]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_networking/index#getting-started-with-nmcli_configuring-and-managing-networking[Getting started with nmcli]
|
||||
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_networking/index#getting-started-with-nmtui_configuring-and-managing-networking[Getting started with nmtui]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-console-configuration.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-enabling-serial-console.adoc[leveloffset=+3]
|
||||
@@ -244,3 +262,7 @@ include::modules/cluster-telemetry.adoc[leveloffset=+1]
|
||||
* If necessary, you can
|
||||
xref:../../../support/remote_health_monitoring/remote-health-reporting.adoc#remote-health-reporting[Remote health reporting].
|
||||
* xref:../../../registry/configuring_registry_storage/configuring-registry-storage-baremetal.adoc#configuring-registry-storage-baremetal[Set up your registry and configure registry storage].
|
||||
|
||||
ifeval::["{context}" == "installing-with-agent-based-installer"]
|
||||
:!agent:
|
||||
endif::[]
|
||||
|
||||
@@ -1,3 +1,7 @@
|
||||
ifeval::["{context}" == "installing-with-agent-based-installer"]
|
||||
:agent:
|
||||
endif::[]
|
||||
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="installing-bare-metal"]
|
||||
= Installing a user-provisioned cluster on bare metal
|
||||
@@ -171,6 +175,20 @@ include::modules/installation-user-infra-machines-pxe.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-network.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-disk.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-retain-disk.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-ignition.adoc[leveloffset=+3]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_networking/index#getting-started-with-nmcli_configuring-and-managing-networking[Getting started with nmcli]
|
||||
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_networking/index#getting-started-with-nmtui_configuring-and-managing-networking[Getting started with nmtui]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-console-configuration.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-enabling-serial-console.adoc[leveloffset=+3]
|
||||
@@ -271,3 +289,7 @@ include::modules/cluster-telemetry.adoc[leveloffset=+1]
|
||||
* xref:../../../post_installation_configuration/cluster-tasks.adoc#available_cluster_customizations[Customize your cluster].
|
||||
* xref:../../../support/remote_health_monitoring/remote-health-reporting.adoc#remote-health-reporting[Remote health reporting]
|
||||
* xref:../../../registry/configuring_registry_storage/configuring-registry-storage-baremetal.adoc#configuring-registry-storage-baremetal[Set up your registry and configure registry storage]
|
||||
|
||||
ifeval::["{context}" == "installing-with-agent-based-installer"]
|
||||
:!agent:
|
||||
endif::[]
|
||||
|
||||
@@ -1,3 +1,7 @@
|
||||
ifeval::["{context}" == "installing-with-agent-based-installer"]
|
||||
:agent:
|
||||
endif::[]
|
||||
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="installing-restricted-networks-bare-metal"]
|
||||
= Installing a user-provisioned bare metal cluster on a disconnected environment
|
||||
@@ -165,6 +169,20 @@ include::modules/installation-user-infra-machines-pxe.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-network.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-disk.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-retain-disk.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-ignition.adoc[leveloffset=+3]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_networking/index#getting-started-with-nmcli_configuring-and-managing-networking[Getting started with nmcli]
|
||||
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_networking/index#getting-started-with-nmtui_configuring-and-managing-networking[Getting started with nmtui]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-console-configuration.adoc[leveloffset=+3]
|
||||
|
||||
include::modules/installation-user-infra-machines-advanced-enabling-serial-console.adoc[leveloffset=+3]
|
||||
@@ -266,3 +284,7 @@ include::modules/cluster-telemetry.adoc[leveloffset=+1]
|
||||
* If necessary, you can
|
||||
xref:../../../support/remote_health_monitoring/remote-health-reporting.adoc#remote-health-reporting[Remote health reporting].
|
||||
* If necessary, see xref:../../../support/remote_health_monitoring/remote-health-reporting.adoc#insights-operator-register-disconnected-cluster_remote-health-reporting[Registering your disconnected cluster]
|
||||
|
||||
ifeval::["{context}" == "installing-with-agent-based-installer"]
|
||||
:!agent:
|
||||
endif::[]
|
||||
|
||||
@@ -52,8 +52,8 @@ include::modules/installing-ocp-agent-manifest-folder.adoc[leveloffset=+3]
|
||||
.Additional resources
|
||||
* xref:../../machine_configuration/machine-configs-configure.adoc#machine-configs-configure[Using MachineConfig objects to configure nodes]
|
||||
|
||||
// Partitioning the disk
|
||||
include::modules/installation-user-infra-machines-advanced.adoc[leveloffset=+3]
|
||||
// Disk partitioning
|
||||
include::modules/installation-user-infra-machines-advanced-disk.adoc[leveloffset=+3]
|
||||
|
||||
// Using ZTP manifests
|
||||
include::modules/installing-ocp-agent-ZTP.adoc[leveloffset=+2]
|
||||
|
||||
158
modules/installation-user-infra-machines-advanced-disk.adoc
Normal file
158
modules/installation-user-infra-machines-advanced-disk.adoc
Normal file
@@ -0,0 +1,158 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * installing/installing_bare_metal/upi/installing-bare-metal.adoc
|
||||
// * installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc
|
||||
// * installing/installing_bare_metal/upi/installing-bare-metal-network-customizations.adoc
|
||||
// * installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc
|
||||
|
||||
ifeval::["{context}" == "installing-with-agent-based-installer"]
|
||||
:agent:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "installing-restricted-networks-bare-metal"]
|
||||
:restricted:
|
||||
endif::[]
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="installation-user-infra-machines-advanced-disk_{context}"]
|
||||
= Disk partitioning
|
||||
|
||||
ifndef::agent[]
|
||||
[role="_abstract"]
|
||||
Disk partitions are created on {product-title} cluster nodes during the {op-system-first} installation. Each {op-system} node of a particular architecture uses the same partition layout, unless you override the default partitioning configuration. During the {op-system} installation, the size of the root file system is increased to use any remaining available space on the target device.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
The use of a custom partition scheme on your node might result in {product-title} not monitoring or alerting on some node partitions. For more information on monitoring host file systems when using custom partitioning, see link:https://access.redhat.com/articles/4766521[Understanding OpenShift File System Monitoring (eviction conditions)].
|
||||
====
|
||||
|
||||
{product-title} monitors the following two filesystem identifiers:
|
||||
|
||||
* `nodefs`, which is the filesystem that contains `/var/lib/kubelet`.
|
||||
* `imagefs`, which is the filesystem that contains `/var/lib/containers`.
|
||||
|
||||
For the default partition scheme, `nodefs` and `imagefs` monitor the same root filesystem, `/`.
|
||||
|
||||
To override the default partitioning when installing {op-system} on an {product-title} cluster node, you must create separate partitions. Consider a situation where you want to add a separate storage partition for your containers and container images. For example, by mounting `/var/lib/containers` in a separate partition, the kubelet separately monitors `/var/lib/containers` as the `imagefs` directory and the root file system as the `nodefs` directory.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
If you have resized your disk size to host a larger file system, consider creating a separate `/var/lib/containers` partition. Consider resizing a disk that has an `xfs` format to reduce CPU time issues caused by a high number of allocation groups.
|
||||
====
|
||||
endif::agent[]
|
||||
ifdef::agent[]
|
||||
[role="_abstract"]
|
||||
In general, you must use the default disk partitioning that is created during the {op-system} installation. However, there are cases where you might want to create a separate partition for a directory that you expect to grow.
|
||||
endif::agent[]
|
||||
|
||||
{product-title} supports the addition of a single partition to attach storage to either the `/var` directory or a subdirectory of `/var`. For example:
|
||||
|
||||
* `/var/lib/containers`: Holds container-related content that can grow
|
||||
as more images and containers are added to a system.
|
||||
* `/var/lib/etcd`: Holds data that you might want to keep separate for purposes such as performance optimization of etcd storage.
|
||||
* `/var`: Holds data that you might want to keep separate for purposes such as auditing.
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
For disk sizes larger than 100GB, and especially larger than 1TB, create a separate `/var` partition.
|
||||
====
|
||||
|
||||
Storing the contents of a `/var` directory separately makes it easier to grow storage for those areas as needed and reinstall {product-title} at a later date so to keep that data intact. This method eliminates the need to re-pull containers or copy large log files during system updates.
|
||||
|
||||
The use of a separate partition for the `/var` directory or a subdirectory of `/var` also prevents data growth in the partitioned directory from filling up the root file system.
|
||||
|
||||
The following procedure sets up a separate `/var` partition by adding a machine config manifest that is wrapped into the Ignition config file for a node type during the preparation phase of an installation.
|
||||
|
||||
ifdef::agent[]
|
||||
.Prerequisites
|
||||
* You have created an `openshift` subdirectory within your installation directory.
|
||||
endif::agent[]
|
||||
|
||||
.Procedure
|
||||
|
||||
ifndef::agent[]
|
||||
. On your installation host, change to the directory that contains the {product-title} installation program and generate the Kubernetes manifests for the cluster:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ openshift-install create manifests --dir <installation_directory>
|
||||
----
|
||||
endif::agent[]
|
||||
|
||||
. Create a Butane config that configures the additional partition. For example, name the file `$HOME/clusterconfig/98-var-partition.bu`, change the disk device name to the name of the storage device on the `worker` systems, and set the storage size as appropriate. This example places the `/var` directory on a separate partition:
|
||||
+
|
||||
[source,yaml,subs="attributes+"]
|
||||
----
|
||||
variant: openshift
|
||||
version: {product-version}.0
|
||||
metadata:
|
||||
labels:
|
||||
machineconfiguration.openshift.io/role: worker
|
||||
name: 98-var-partition
|
||||
storage:
|
||||
disks:
|
||||
- device: /dev/disk/by-id/<device_name>
|
||||
partitions:
|
||||
- label: var
|
||||
start_mib: <partition_start_offset>
|
||||
size_mib: <partition_size>
|
||||
number: 5
|
||||
filesystems:
|
||||
- device: /dev/disk/by-partlabel/var
|
||||
path: /var
|
||||
format: xfs
|
||||
mount_options: [defaults, prjquota]
|
||||
with_mount_unit: true
|
||||
----
|
||||
+
|
||||
where:
|
||||
+
|
||||
`<device_name>`:: Specifies the storage device name of the disk that you want to partition.
|
||||
`<partition_start_offset>`:: Specifies the minimum offset value for the boot disk. For best performance, specify a minimum offset value of 25000 mebibytes. The root file system is automatically resized to fill all available space up to the specified offset. If no offset value is specified, or if the specified value is smaller than the recommended minimum, the resulting root file system will be too small, and future reinstalls of {op-system} might overwrite the beginning of the data partition.
|
||||
`<partition_size>`:: Specifies the size of the data partition in mebibytes.
|
||||
`mount_options`:: The `prjquota` mount option must be enabled for filesystems used for container storage.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
When creating a separate `/var` partition, you cannot use different instance types for compute nodes, if the different instance types do not have the same device name.
|
||||
====
|
||||
|
||||
. Create a manifest from the Butane config and save it to the `clusterconfig/openshift` directory. For example, run the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
|
||||
----
|
||||
|
||||
ifndef::agent[]
|
||||
. Create the Ignition config files by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ openshift-install create ignition-configs --dir <installation_directory>
|
||||
----
|
||||
* `<installation_directory>`: Specify the name installation directory.
|
||||
+
|
||||
Ignition config files are created for the bootstrap, control plane, and compute nodes in the installation directory:
|
||||
+
|
||||
----
|
||||
.
|
||||
├── auth
|
||||
│ ├── kubeadmin-password
|
||||
│ └── kubeconfig
|
||||
├── bootstrap.ign
|
||||
├── master.ign
|
||||
├── metadata.json
|
||||
└── worker.ign
|
||||
----
|
||||
+
|
||||
The files in the `<installation_directory>/manifest` and `<installation_directory>/openshift` directories are wrapped into the Ignition config files, including the file that contains the `98-var-partition` custom `MachineConfig` object.
|
||||
|
||||
. Optional: You can apply the custom disk partitioning by referencing the Ignition config files during the {op-system} installations.
|
||||
endif::agent[]
|
||||
|
||||
ifeval::["{context}" == "installing-with-agent-based-installer"]
|
||||
:!agent:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "installing-restricted-networks-bare-metal"]
|
||||
:!restricted:
|
||||
endif::[]
|
||||
@@ -0,0 +1,34 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * installing/installing_bare_metal/upi/installing-bare-metal.adoc
|
||||
// * installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc
|
||||
// * installing/installing_bare_metal/upi/installing-bare-metal-network-customizations.adoc
|
||||
// * installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc
|
||||
|
||||
ifeval::["{context}" == "installing-restricted-networks-bare-metal"]
|
||||
:restricted:
|
||||
endif::[]
|
||||
|
||||
:_mod-docs-content-type: REFERENCE
|
||||
[id="installation-user-infra-machines-advanced-ignition_{context}"]
|
||||
= Identifying Ignition configs
|
||||
|
||||
[role="_abstract"]
|
||||
When doing an {op-system} manual installation, there are two types of Ignition configs that you can provide, with different reasons for providing each one:
|
||||
|
||||
* **Permanent install Ignition config**: Every manual {op-system} installation needs to pass one of the Ignition config files generated by `openshift-installer`, such as `bootstrap.ign`, `master.ign` and `worker.ign`, to carry out the installation.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
It is not recommended to modify these Ignition config files directly. You can update the manifest files that are wrapped into the Ignition config files, as outlined in examples in the preceding sections.
|
||||
====
|
||||
|
||||
For PXE installations, you can pass the Ignition configs on the `APPEND` line using the `coreos.inst.ignition_url=` option. For ISO installations, after the ISO boots to the shell prompt, you must identify the Ignition config on the `coreos-installer` command line with the `--ignition-url=` option. In both cases, only HTTP and HTTPS protocols are supported.
|
||||
|
||||
* **Live install Ignition config**: This type can be created by using the `coreos-installer` `customize` subcommand of `coreos-installer` and its various options. With this method, the Ignition config passes to the live install medium, runs immediately upon booting, and performs setup tasks before or after the {op-system} system installs to disk. This method must be only used for performing tasks that must be done once and not applied again later, such as with advanced partitioning that cannot be done using a machine config.
|
||||
|
||||
For PXE or ISO boots, you can create the Ignition config and `APPEND` the `ignition.config.url=` option to identify the location of the Ignition config. You also need to append `ignition.firstboot ignition.platform.id=metal` else the `ignition.config.url` option is ignored.
|
||||
|
||||
ifeval::["{context}" == "installing-restricted-networks-bare-metal"]
|
||||
:!restricted:
|
||||
endif::[]
|
||||
@@ -0,0 +1,69 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * installing/installing_bare_metal/upi/installing-bare-metal.adoc
|
||||
// * installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc
|
||||
// * installing/installing_bare_metal/upi/installing-bare-metal-network-customizations.adoc
|
||||
// * installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc
|
||||
|
||||
ifeval::["{context}" == "installing-restricted-networks-bare-metal"]
|
||||
:restricted:
|
||||
endif::[]
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="installation-user-infra-machines-advanced_network_{context}"]
|
||||
= Using advanced networking options for PXE and ISO installations
|
||||
|
||||
[role="_abstract"]
|
||||
Networking for {product-title} nodes uses DHCP by default to gather all necessary configuration settings.
|
||||
|
||||
To set up static IP addresses or configure special settings, such as bonding, you can do one of the following:
|
||||
|
||||
* Pass special kernel parameters when you boot the live installer.
|
||||
|
||||
* Use a machine config to copy networking files to the installed system.
|
||||
|
||||
* Configure networking from a live installer shell prompt, then copy those settings to the installed system so that they take effect when the installed system first boots.
|
||||
|
||||
To configure a PXE or iPXE installation, use one of the following options:
|
||||
|
||||
* See the "Advanced RHCOS installation reference" tables.
|
||||
|
||||
* Use a machine config to copy networking files to the installed system.
|
||||
|
||||
To configure an ISO installation, use the following procedure.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Boot the ISO installer.
|
||||
|
||||
. From the live system shell prompt, configure networking for the live system by using available RHEL tools, such as `nmcli` or `nmtui`.
|
||||
|
||||
. Run the `coreos-installer` command to install the system, adding the `--copy-network` option to copy networking configuration. For example:
|
||||
+
|
||||
ifndef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
$ sudo coreos-installer install --copy-network \
|
||||
--ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
ifdef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
$ sudo coreos-installer install --copy-network \
|
||||
--ignition-url=http://host/worker.ign \
|
||||
--offline \
|
||||
/dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
The `--copy-network` option only copies networking configuration found under `/etc/NetworkManager/system-connections`. In particular, it does not copy the system hostname.
|
||||
====
|
||||
|
||||
. Reboot into the installed system.
|
||||
|
||||
ifeval::["{context}" == "installing-restricted-networks-bare-metal"]
|
||||
:!restricted:
|
||||
endif::[]
|
||||
@@ -0,0 +1,113 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * installing/installing_bare_metal/upi/installing-bare-metal.adoc
|
||||
// * installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc
|
||||
// * installing/installing_bare_metal/upi/installing-bare-metal-network-customizations.adoc
|
||||
// * installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc
|
||||
|
||||
ifeval::["{context}" == "installing-restricted-networks-bare-metal"]
|
||||
:restricted:
|
||||
endif::[]
|
||||
|
||||
:_mod-docs-content-type: REFERENCE
|
||||
[id="installation-user-infra-machines-advanced-retain-disk_{context}"]
|
||||
= Examples of retaining existing partitions
|
||||
|
||||
[role="_abstract"]
|
||||
For an ISO installation, you can add options to the `coreos-installer` command that causes the installation program to maintain one or more existing partitions. For a PXE installation, you can add `coreos.inst.*` options to the `APPEND` parameter to preserve partitions.
|
||||
|
||||
Saved partitions might be data partitions from an existing {product-title} system. You can identify the disk partitions you want to keep either by partition label or by number.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
If you save existing partitions, and those partitions do not leave enough space for {op-system}, the installation fails without damaging the saved partitions.
|
||||
====
|
||||
|
||||
The following examples preserves any existing partition during an ISO installation in which the partition label begins with `data` (`data*`):
|
||||
|
||||
ifndef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partlabel 'data*' \
|
||||
/dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
ifdef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partlabel 'data*' \
|
||||
--offline \
|
||||
/dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
The following example runs the `coreos-installer` in a way that preserves
|
||||
the sixth (6) partition on the disk:
|
||||
|
||||
ifndef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partindex 6 /dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
ifdef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partindex 6 \
|
||||
--offline \
|
||||
/dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
The following example preserves partitions 5 and higher:
|
||||
|
||||
ifndef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partindex 5- /dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
ifdef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partindex 5- \
|
||||
--offline \
|
||||
/dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
In the earlier examples where partition saving is used, `coreos-installer` recreates the partition immediately.
|
||||
|
||||
The following examples preserve existing partitions during a PXE installation. The following `APPEND` option preserves any partition in which the partition label begins with 'data' ('data*').
|
||||
|
||||
[source,terminal]
|
||||
----
|
||||
coreos.inst.save_partlabel=data*
|
||||
----
|
||||
|
||||
The following `APPEND` option preserves partitions 5 and higher:
|
||||
|
||||
[source,terminal]
|
||||
----
|
||||
coreos.inst.save_partindex=5-
|
||||
----
|
||||
|
||||
The following `APPEND` option preserves partition 6:
|
||||
|
||||
[source,terminal]
|
||||
----
|
||||
coreos.inst.save_partindex=6
|
||||
----
|
||||
|
||||
ifeval::["{context}" == "installing-restricted-networks-bare-metal"]
|
||||
:!restricted:
|
||||
endif::[]
|
||||
@@ -5,364 +5,23 @@
|
||||
// * installing/installing_bare_metal/upi/installing-bare-metal-network-customizations.adoc
|
||||
// * installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc
|
||||
|
||||
ifeval::["{context}" == "installing-with-agent-based-installer"]
|
||||
:agent:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "installing-restricted-networks-bare-metal"]
|
||||
:restricted:
|
||||
endif::[]
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
ifndef::agent[]
|
||||
:_mod-docs-content-type: CONCEPT
|
||||
[id="installation-user-infra-machines-advanced_{context}"]
|
||||
= Advanced {op-system} installation configuration
|
||||
|
||||
A key benefit for manually provisioning the {op-system-first}
|
||||
nodes for {product-title} is to be able to do configuration that is not
|
||||
available through default {product-title} installation methods.
|
||||
This section describes some of the configurations that you can do using
|
||||
techniques that include:
|
||||
[role="_abstract"]
|
||||
A key benefit for manually provisioning the {op-system-first} nodes for {product-title} is to be able to do configuration that is not available through default {product-title} installation methods. This section describes some of the configurations that you can do using techniques that include:
|
||||
|
||||
* Passing kernel arguments to the live installer
|
||||
* Running `coreos-installer` manually from the live system
|
||||
* Customizing a live ISO or PXE boot image
|
||||
|
||||
The advanced configuration topics for manual {op-system-first}
|
||||
installations detailed in this section relate to disk partitioning, networking, and using Ignition configs in different ways.
|
||||
The advanced configuration topics for manual {op-system-first} installations detailed in this section relate to disk partitioning, networking, and using Ignition configs in different ways.
|
||||
|
||||
[id="installation-user-infra-machines-advanced_network_{context}"]
|
||||
== Using advanced networking options for PXE and ISO installations
|
||||
Networking for {product-title} nodes uses DHCP by default to gather all
|
||||
necessary configuration settings. To set up static IP addresses or configure special settings, such as bonding, you can do one of the following:
|
||||
|
||||
* Pass special kernel parameters when you boot the live installer.
|
||||
|
||||
* Use a machine config to copy networking files to the installed system.
|
||||
|
||||
* Configure networking from a live installer shell prompt, then copy those settings to the installed system so that they take effect when the installed system first boots.
|
||||
|
||||
To configure a PXE or iPXE installation, use one of the following options:
|
||||
|
||||
* See the "Advanced RHCOS installation reference" tables.
|
||||
* Use a machine config to copy networking files to the installed system.
|
||||
|
||||
To configure an ISO installation, use the following procedure.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Boot the ISO installer.
|
||||
|
||||
. From the live system shell prompt, configure networking for the live system using available RHEL tools, such as `nmcli` or `nmtui`.
|
||||
|
||||
. Run the `coreos-installer` command to install the system, adding the `--copy-network` option to copy networking configuration. For example:
|
||||
+
|
||||
ifndef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
$ sudo coreos-installer install --copy-network \
|
||||
--ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
ifdef::restricted[]
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ sudo coreos-installer install --copy-network \
|
||||
--ignition-url=http://host/worker.ign \
|
||||
--offline \
|
||||
/dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
The `--copy-network` option only copies networking configuration found under `/etc/NetworkManager/system-connections`. In particular, it does not copy the system hostname.
|
||||
====
|
||||
|
||||
. Reboot into the installed system.
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* See link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_networking/index#getting-started-with-nmcli_configuring-and-managing-networking[Getting started with nmcli] and link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_networking/index#getting-started-with-nmtui_configuring-and-managing-networking[Getting started with nmtui] in the {op-system-base} 8 documentation for more information about the `nmcli` and `nmtui` tools.
|
||||
|
||||
[id="installation-user-infra-machines-advanced_disk_{context}"]
|
||||
== Disk partitioning
|
||||
|
||||
Disk partitions are created on {product-title} cluster nodes during the {op-system-first} installation. Each {op-system} node of a particular architecture uses the same partition layout, unless you override the default partitioning configuration. During the {op-system} installation, the size of the root file system is increased to use any remaining available space on the target device.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
The use of a custom partition scheme on your node might result in {product-title} not monitoring or alerting on some node partitions. If you override the default partitioning, see link:https://access.redhat.com/articles/4766521[Understanding OpenShift File System Monitoring (eviction conditions)] for more information about how {product-title} monitors your host file systems.
|
||||
====
|
||||
|
||||
{product-title} monitors the following two filesystem identifiers:
|
||||
|
||||
* `nodefs`, which is the filesystem that contains `/var/lib/kubelet`
|
||||
* `imagefs`, which is the filesystem that contains `/var/lib/containers`
|
||||
|
||||
For the default partition scheme, `nodefs` and `imagefs` monitor the same root filesystem, `/`.
|
||||
|
||||
To override the default partitioning when installing {op-system} on an {product-title} cluster node, you must create separate partitions. Consider a situation where you want to add a separate storage partition for your containers and container images. For example, by mounting `/var/lib/containers` in a separate partition, the kubelet separately monitors `/var/lib/containers` as the `imagefs` directory and the root file system as the `nodefs` directory.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
If you have resized your disk size to host a larger file system, consider creating a separate `/var/lib/containers` partition. Consider resizing a disk that has an `xfs` format to reduce CPU time issues caused by a high number of allocation groups.
|
||||
====
|
||||
|
||||
[id="installation-user-infra-machines-advanced_vardisk_{context}"]
|
||||
=== Creating a separate `/var` partition
|
||||
endif::agent[]
|
||||
|
||||
ifdef::agent[]
|
||||
[id="installing-ocp-agent-disk-partition_{context}"]
|
||||
= Disk partitioning
|
||||
|
||||
endif::agent[]
|
||||
|
||||
In general, you should use the default disk partitioning that is created during the {op-system} installation. However, there are cases where you might want to create a separate partition for a directory that you expect to grow.
|
||||
|
||||
{product-title} supports the addition of a single partition to attach
|
||||
storage to either the `/var` directory or a subdirectory of `/var`.
|
||||
For example:
|
||||
|
||||
* `/var/lib/containers`: Holds container-related content that can grow
|
||||
as more images and containers are added to a system.
|
||||
* `/var/lib/etcd`: Holds data that you might want to keep separate for purposes such as performance optimization of etcd storage.
|
||||
* `/var`: Holds data that you might want to keep separate for purposes such as auditing.
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
For disk sizes larger than 100GB, and especially larger than 1TB, create a separate `/var` partition.
|
||||
====
|
||||
|
||||
Storing the contents of a `/var` directory separately makes it easier to grow storage for those areas as needed and reinstall {product-title} at a later date and keep that data intact. With this method, you will not have to pull all your containers again, nor will you have to copy massive log files when you update systems.
|
||||
|
||||
The use of a separate partition for the `/var` directory or a subdirectory of `/var` also prevents data growth in the partitioned directory from filling up the root file system.
|
||||
|
||||
The following procedure sets up a separate `/var` partition by adding a machine config manifest that is wrapped into the Ignition config file for a node type during the preparation phase of an installation.
|
||||
|
||||
ifdef::agent[]
|
||||
.Prerequisites
|
||||
* You have created an `openshift` subdirectory within your installation directory.
|
||||
endif::agent[]
|
||||
|
||||
.Procedure
|
||||
|
||||
ifndef::agent[]
|
||||
. On your installation host, change to the directory that contains the {product-title} installation program and generate the Kubernetes manifests for the cluster:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ openshift-install create manifests --dir <installation_directory>
|
||||
----
|
||||
endif::agent[]
|
||||
|
||||
. Create a Butane config that configures the additional partition. For example, name the file `$HOME/clusterconfig/98-var-partition.bu`, change the disk device name to the name of the storage device on the `worker` systems, and set the storage size as appropriate. This example places the `/var` directory on a separate partition:
|
||||
+
|
||||
[source,yaml,subs="attributes+"]
|
||||
----
|
||||
variant: openshift
|
||||
version: {product-version}.0
|
||||
metadata:
|
||||
labels:
|
||||
machineconfiguration.openshift.io/role: worker
|
||||
name: 98-var-partition
|
||||
storage:
|
||||
disks:
|
||||
- device: /dev/disk/by-id/<device_name> <1>
|
||||
partitions:
|
||||
- label: var
|
||||
start_mib: <partition_start_offset> <2>
|
||||
size_mib: <partition_size> <3>
|
||||
number: 5
|
||||
filesystems:
|
||||
- device: /dev/disk/by-partlabel/var
|
||||
path: /var
|
||||
format: xfs
|
||||
mount_options: [defaults, prjquota] <4>
|
||||
with_mount_unit: true
|
||||
----
|
||||
+
|
||||
<1> The storage device name of the disk that you want to partition.
|
||||
<2> When adding a data partition to the boot disk, a minimum offset value of 25000 mebibytes is recommended. The root file system is automatically resized to fill all available space up to the specified offset. If no offset value is specified, or if the specified value is smaller than the recommended minimum, the resulting root file system will be too small, and future reinstalls of {op-system} might overwrite the beginning of the data partition.
|
||||
<3> The size of the data partition in mebibytes.
|
||||
<4> The `prjquota` mount option must be enabled for filesystems used for container storage.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
When creating a separate `/var` partition, you cannot use different instance types for compute nodes, if the different instance types do not have the same device name.
|
||||
====
|
||||
|
||||
. Create a manifest from the Butane config and save it to the `clusterconfig/openshift` directory. For example, run the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
|
||||
----
|
||||
|
||||
ifndef::agent[]
|
||||
. Create the Ignition config files:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ openshift-install create ignition-configs --dir <installation_directory> <1>
|
||||
----
|
||||
<1> For `<installation_directory>`, specify the same installation directory.
|
||||
+
|
||||
Ignition config files are created for the bootstrap, control plane, and compute nodes in the installation directory:
|
||||
+
|
||||
----
|
||||
.
|
||||
├── auth
|
||||
│ ├── kubeadmin-password
|
||||
│ └── kubeconfig
|
||||
├── bootstrap.ign
|
||||
├── master.ign
|
||||
├── metadata.json
|
||||
└── worker.ign
|
||||
----
|
||||
+
|
||||
The files in the `<installation_directory>/manifest` and `<installation_directory>/openshift` directories are wrapped into the Ignition config files, including the file that contains the `98-var-partition` custom `MachineConfig` object.
|
||||
|
||||
.Next steps
|
||||
|
||||
* You can apply the custom disk partitioning by referencing the Ignition config files during the {op-system} installations.
|
||||
|
||||
[id="installation-user-infra-machines-advanced_retaindisk_{context}"]
|
||||
=== Retaining existing partitions
|
||||
|
||||
For an ISO installation, you can add options to the `coreos-installer` command
|
||||
that cause the installer to maintain one or more existing partitions.
|
||||
For a PXE installation, you can add `coreos.inst.*` options to the `APPEND` parameter to preserve partitions.
|
||||
|
||||
Saved partitions might be data partitions from an existing {product-title} system. You can identify the disk partitions you want to keep either by partition label or by number.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
If you save existing partitions, and those partitions do not leave enough space for {op-system}, the installation will fail without damaging the saved partitions.
|
||||
====
|
||||
|
||||
.Retaining existing partitions during an ISO installation
|
||||
|
||||
This example preserves any partition in which the partition label begins with `data` (`data*`):
|
||||
|
||||
ifndef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partlabel 'data*' \
|
||||
/dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
ifdef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partlabel 'data*' \
|
||||
--offline \
|
||||
/dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
The following example illustrates running the `coreos-installer` in a way that preserves
|
||||
the sixth (6) partition on the disk:
|
||||
|
||||
ifndef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partindex 6 /dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
ifdef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partindex 6 \
|
||||
--offline \
|
||||
/dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
This example preserves partitions 5 and higher:
|
||||
|
||||
ifndef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partindex 5- /dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
ifdef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
|
||||
--save-partindex 5- \
|
||||
--offline \
|
||||
/dev/disk/by-id/scsi-<serial_number>
|
||||
----
|
||||
endif::[]
|
||||
|
||||
In the previous examples where partition saving is used, `coreos-installer` recreates the partition immediately.
|
||||
|
||||
.Retaining existing partitions during a PXE installation
|
||||
|
||||
This `APPEND` option preserves any partition in which the partition label begins with 'data' ('data*'):
|
||||
|
||||
[source,terminal]
|
||||
----
|
||||
coreos.inst.save_partlabel=data*
|
||||
----
|
||||
|
||||
This `APPEND` option preserves partitions 5 and higher:
|
||||
|
||||
[source,terminal]
|
||||
----
|
||||
coreos.inst.save_partindex=5-
|
||||
----
|
||||
|
||||
This `APPEND` option preserves partition 6:
|
||||
|
||||
[source,terminal]
|
||||
----
|
||||
coreos.inst.save_partindex=6
|
||||
----
|
||||
|
||||
[id="installation-user-infra-machines-advanced_ignition_{context}"]
|
||||
== Identifying Ignition configs
|
||||
When doing an {op-system} manual installation, there are two types of Ignition configs that you can provide, with different reasons for providing each one:
|
||||
|
||||
* **Permanent install Ignition config**: Every manual {op-system} installation
|
||||
needs to pass one of the Ignition config files generated by `openshift-installer`,
|
||||
such as `bootstrap.ign`, `master.ign` and `worker.ign`, to carry out the
|
||||
installation.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
It is not recommended to modify these Ignition config files directly. You can update the manifest files that are wrapped into the Ignition config files, as outlined in examples in the preceding sections.
|
||||
====
|
||||
|
||||
For PXE installations, you pass the Ignition configs on the `APPEND` line using the
|
||||
`coreos.inst.ignition_url=` option. For ISO installations, after the ISO boots to
|
||||
the shell prompt, you identify the Ignition config on the `coreos-installer`
|
||||
command line with the `--ignition-url=` option. In both cases, only HTTP and HTTPS
|
||||
protocols are supported.
|
||||
|
||||
* **Live install Ignition config**: This type can be created by using the `coreos-installer` `customize` subcommand and its various options. With this method, the Ignition config passes to the live install medium, runs immediately upon booting, and performs setup tasks before or after the {op-system} system installs to disk. This method should only be used for performing tasks that must be done once and not applied again later, such as with advanced partitioning that cannot be done using a machine config.
|
||||
|
||||
For PXE or ISO boots, you can create the Ignition config
|
||||
and `APPEND` the `ignition.config.url=` option to identify the location of
|
||||
the Ignition config. You also need to append `ignition.firstboot ignition.platform.id=metal`
|
||||
or the `ignition.config.url` option will be ignored.
|
||||
endif::agent[]
|
||||
|
||||
ifeval::["{context}" == "installing-with-agent-based-installer"]
|
||||
:!agent:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "installing-restricted-networks-bare-metal"]
|
||||
:!restricted:
|
||||
endif::[]
|
||||
@@ -52,8 +52,9 @@ You can add or change configuration settings in your Ignition configs before sav
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ curl -k http://<HTTP_server>/bootstrap.ign <1>
|
||||
$ curl -k http://<HTTP_server>/bootstrap.ign
|
||||
----
|
||||
* <HTTP_server>: Replace `bootstrap.ign` with `master.ign` or `worker.ign` in the command to validate that the Ignition config files for the control plane and compute nodes are also available.
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
@@ -62,9 +63,7 @@ $ curl -k http://<HTTP_server>/bootstrap.ign <1>
|
||||
Dload Upload Total Spent Left Speed
|
||||
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
|
||||
----
|
||||
+
|
||||
Replace `bootstrap.ign` with `master.ign` or `worker.ign` in the command to validate that the Ignition config files for the control plane and compute nodes are also available.
|
||||
+
|
||||
|
||||
. Although it is possible to obtain the {op-system} images that are required for your preferred method of installing operating system instances from the
|
||||
ifdef::openshift-enterprise[]
|
||||
ifndef::ibm-power[]
|
||||
@@ -132,19 +131,19 @@ It is possible to interrupt the {op-system} installation boot process to add ker
|
||||
ifdef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
$ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \ <1>
|
||||
--ignition-hash=sha512-<digest> --offline <2>
|
||||
$ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \
|
||||
--ignition-hash=sha512-<digest> --offline
|
||||
----
|
||||
endif::[]
|
||||
ifndef::restricted[]
|
||||
[source,terminal]
|
||||
----
|
||||
$ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \ <1>
|
||||
--ignition-hash=sha512-<digest> <2>
|
||||
$ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \
|
||||
--ignition-hash=sha512-<digest>
|
||||
----
|
||||
endif::[]
|
||||
<1> You must run the `coreos-installer` command by using `sudo`, because the `core` user does not have the required root privileges to perform the installation.
|
||||
<2> The `--ignition-hash` option is required when the Ignition config file is obtained through an HTTP URL to validate the authenticity of the Ignition config file on the cluster node. `<digest>` is the Ignition config file SHA512 digest obtained in a preceding step.
|
||||
* `<device>`: You must run the `coreos-installer` command by using `sudo`, because the `core` user does not have the required root privileges to perform the installation.
|
||||
* `<digest>`: The `--ignition-hash` option is required when the Ignition config file is obtained through an HTTP URL to validate the authenticity of the Ignition config file on the cluster node. `<digest>` is the Ignition config file SHA512 digest obtained in a preceding step.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
@@ -162,7 +161,6 @@ $ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installatio
|
||||
----
|
||||
endif::[]
|
||||
ifndef::restricted[]
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda \
|
||||
|
||||
@@ -18,6 +18,7 @@ endif::[]
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="installation-user-infra-machines-pxe_{context}"]
|
||||
|
||||
ifndef::only-pxe[]
|
||||
= Installing {op-system} by using PXE or iPXE booting
|
||||
|
||||
@@ -27,6 +28,7 @@ ifdef::only-pxe[]
|
||||
|
||||
endif::only-pxe[]
|
||||
|
||||
[role="_abstract"]
|
||||
ifndef::only-pxe[]
|
||||
You can use PXE or iPXE booting to install {op-system} on the machines.
|
||||
endif::only-pxe[]
|
||||
@@ -64,9 +66,11 @@ installation, do not delete these files.
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ curl -k http://<HTTP_server>/bootstrap.ign <1>
|
||||
$ curl -k http://<HTTP_server>/bootstrap.ign
|
||||
----
|
||||
+
|
||||
* `<HTTP_server>`: Replace `bootstrap.ign` with `master.ign` or `worker.ign` in the command to validate that the Ignition config files for the control plane and compute nodes are also available.
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
@@ -74,9 +78,6 @@ $ curl -k http://<HTTP_server>/bootstrap.ign <1>
|
||||
Dload Upload Total Spent Left Speed
|
||||
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
|
||||
----
|
||||
+
|
||||
Replace `bootstrap.ign` with `master.ign` or `worker.ign` in the command to validate
|
||||
that the Ignition config files for the control plane and compute nodes are also available.
|
||||
|
||||
. Although it is possible to obtain the {op-system} `kernel`, `initramfs` and `rootfs`
|
||||
files that are required for your preferred method of installing operating system instances from the
|
||||
@@ -135,8 +136,7 @@ for this procedure.
|
||||
{op-system} QCOW2 images are not supported for this installation type.
|
||||
====
|
||||
+
|
||||
The file names contain the {product-title} version number.
|
||||
They resemble the following examples:
|
||||
The file names contain the {product-title} version number. They resemble the following examples:
|
||||
+
|
||||
ifndef::openshift-origin[]
|
||||
** `kernel`: `rhcos-<version>-live-kernel-<architecture>`
|
||||
@@ -169,12 +169,10 @@ ifdef::only-pxe[]
|
||||
endif::only-pxe[]
|
||||
+
|
||||
ifndef::only-pxe[]
|
||||
Modify one of the following example menu entries for your environment and verify
|
||||
that the image and Ignition files are properly accessible:
|
||||
. Modify one of the following example menu entries for your environment and verify that the image and Ignition files are properly accessible:
|
||||
endif::only-pxe[]
|
||||
|
||||
ifdef::only-pxe[]
|
||||
Modify the following example menu entry for your environment and verify that the image and Ignition files are properly accessible:
|
||||
. Modify the following example menu entry for your environment and verify that the image and Ignition files are properly accessible:
|
||||
endif::only-pxe[]
|
||||
ifndef::only-pxe[]
|
||||
** For PXE (`x86_64`):
|
||||
@@ -185,21 +183,15 @@ DEFAULT pxeboot
|
||||
TIMEOUT 20
|
||||
PROMPT 0
|
||||
LABEL pxeboot
|
||||
KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> <1>
|
||||
APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign <2> <3>
|
||||
KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture>
|
||||
APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign
|
||||
----
|
||||
<1> Specify the location of the live `kernel` file that you uploaded to your HTTP
|
||||
server.
|
||||
The URL must be HTTP, TFTP, or FTP; HTTPS and NFS are not supported.
|
||||
<2> If you use multiple NICs, specify a single interface in the `ip` option.
|
||||
For example, to use DHCP on a NIC that is named `eno1`, set `ip=eno1:dhcp`.
|
||||
<3> Specify the locations of the {op-system} files that you uploaded to your
|
||||
HTTP server. The `initrd` parameter value is the location of the `initramfs` file,
|
||||
the `coreos.live.rootfs_url` parameter value is the location of the
|
||||
`rootfs` file, and the `coreos.inst.ignition_url` parameter value is the
|
||||
location of the bootstrap Ignition config file.
|
||||
You can also add more kernel arguments to the `APPEND` line to configure networking
|
||||
or other boot options.
|
||||
+
|
||||
where:
|
||||
+
|
||||
`kernel`:: Specify the location of the live `kernel` file that you uploaded to your HTTP
|
||||
server. The URL must be HTTP, TFTP, or FTP; HTTPS and NFS are not supported.
|
||||
`initrd=main`:: If you use multiple NICs, specify a single interface in the `ip` option. For example, to use DHCP on a NIC that is named `eno1`, set `ip=eno1:dhcp`. Specify the locations of the {op-system} files that you uploaded to your HTTP server. The `initrd` parameter value is the location of the `initramfs` file, the `coreos.live.rootfs_url` parameter value is the location of the `rootfs` file, and the `coreos.inst.ignition_url` parameter value is the location of the bootstrap Ignition config file. You can also add more kernel arguments to the `APPEND` line to configure networking or other boot options.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
@@ -214,19 +206,13 @@ endif::openshift-origin[]
|
||||
):
|
||||
+
|
||||
----
|
||||
kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign <1> <2>
|
||||
initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img <3>
|
||||
kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign
|
||||
initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img
|
||||
boot
|
||||
----
|
||||
<1> Specify the locations of the {op-system} files that you uploaded to your
|
||||
HTTP server. The `kernel` parameter value is the location of the `kernel` file,
|
||||
the `initrd=main` argument is needed for booting on UEFI systems,
|
||||
the `coreos.live.rootfs_url` parameter value is the location of the `rootfs` file,
|
||||
and the `coreos.inst.ignition_url` parameter value is the
|
||||
location of the bootstrap Ignition config file.
|
||||
<2> If you use multiple NICs, specify a single interface in the `ip` option.
|
||||
`kernel`:: Specify the locations of the {op-system} files that you uploaded to your HTTP server. The `kernel` parameter value is the location of the `kernel` file, the `initrd=main` argument is needed for booting on UEFI systems, the `coreos.live.rootfs_url` parameter value is the location of the `rootfs` file, and the `coreos.inst.ignition_url` parameter value is the location of the bootstrap Ignition config file. If you use multiple NICs, specify a single interface in the `ip` option.
|
||||
For example, to use DHCP on a NIC that is named `eno1`, set `ip=eno1:dhcp`.
|
||||
<3> Specify the location of the `initramfs` file that you uploaded to your HTTP server.
|
||||
`initrd`:: Specify the location of the `initramfs` file that you uploaded to your HTTP server.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
@@ -245,16 +231,17 @@ ifndef::only-pxe,openshift-origin[]
|
||||
+
|
||||
----
|
||||
menuentry 'Install CoreOS' {
|
||||
linux rhcos-<version>-live-kernel-<architecture> coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign <1> <2>
|
||||
initrd rhcos-<version>-live-initramfs.<architecture>.img <3>
|
||||
linux rhcos-<version>-live-kernel-<architecture> coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign
|
||||
initrd rhcos-<version>-live-initramfs.<architecture>.img
|
||||
}
|
||||
----
|
||||
<1> Specify the locations of the {op-system} files that you uploaded to your
|
||||
HTTP/TFTP server. The `kernel` parameter value is the location of the `kernel` file on your TFTP server.
|
||||
The `coreos.live.rootfs_url` parameter value is the location of the `rootfs` file, and the `coreos.inst.ignition_url` parameter value is the location of the bootstrap Ignition config file on your HTTP Server.
|
||||
<2> If you use multiple NICs, specify a single interface in the `ip` option.
|
||||
+
|
||||
where:
|
||||
+
|
||||
`coreos.live.rootfs_url`:: Specify the locations of the {op-system} files that you uploaded to your HTTP/TFTP server.
|
||||
`kernel`:: The `kernel` parameter value is the location of the `kernel` file on your TFTP server. The `coreos.live.rootfs_url` parameter value is the location of the `rootfs` file, and the `coreos.inst.ignition_url` parameter value is the location of the bootstrap Ignition config file on your HTTP Server. If you use multiple NICs, specify a single interface in the `ip` option.
|
||||
For example, to use DHCP on a NIC that is named `eno1`, set `ip=eno1:dhcp`.
|
||||
<3> Specify the location of the `initramfs` file that you uploaded to your TFTP server.
|
||||
`initrd rhcos`:: Specify the location of the `initramfs` file that you uploaded to your TFTP server.
|
||||
|
||||
endif::only-pxe,openshift-origin[]
|
||||
|
||||
|
||||
Reference in New Issue
Block a user