BareMetalHostProfile¶
This section describes the BareMetalHostProfile
resource used
in Mirantis Container Cloud API
to define how the storage devices and operating system
are provisioned and configured.
For demonstration purposes, the Container Cloud BareMetalHostProfile
custom resource (CR) is split into the following major sections:
metadata¶
The Container Cloud BareMetalHostProfile
CR contains
the following fields:
apiVersion
API version of the object that is
metal3.io/v1alpha1
.
kind
Object type that is
BareMetalHostProfile
.
metadata
The
metadata
field contains the following subfields:name
Name of the bare metal host profile.
namespace
Project in which the bare metal host profile was created.
Configuration example:
apiVersion: metal3.io/v1alpha1
kind: BareMetalHostProfile
metadata:
name: default
namespace: default
spec¶
The spec
field of BareMetalHostProfile
object contains
the fields to customize your hardware configuration:
Warning
All data will be wiped during cluster deployment on devices
defined directly or indirectly in the fileSystems
list of
BareMetalHostProfile
. For example:
A raw device partition with a file system on it
A device partition in a volume group with a logical volume that has a file system on it
An mdadm RAID device with a file system on it
An LVM RAID device with a file system on it
The wipe
field is always considered true
for these devices.
The false
value is ignored.
Therefore, to prevent data loss, move the necessary data from these file systems to another server beforehand, if required.
devices
List of definitions of the physical storage devices. To configure more than three storage devices per host, add additional devices to this list. Each
device
in the list can have one or morepartitions
defined by the list in thepartitions
field.Each
device
in the list can have the following fields in theproperties
section that affect the selection of the specific device when the profile is applied to a host:type
(optional, string)The device type. Possible values:
hdd
,ssd
,nvme
. This property is used to filter selected devices by type.
minSizeGiB
,maxSizeGiB
(optional, string)The lower and upper limit of the selected device size. Only the devices matching these criteria are considered for allocation. Omitted parameter means no upper or lower limit.
The
minSize
andmaxSize
parameter names are also available for the same purpose.Caution
Mirantis recommends using only one parameter name type and units throughout the configuration files. If both
sizeGiB
andsize
are used,sizeGiB
is ignored during deployment and the suffix is adjusted accordingly. For example,1.5Gi
will be serialized as1536Mi
. The size without units is counted in bytes. For example,size: 120
means 120 bytes.
byName
(optional, string)The specific device name to be selected during deployment, such as
dev/sda
.
Warning
With NVME devices and certain hardware disk controllers, you cannot reliably select such device by the system name. Use the
workBy
field to ensure reliable referencing to devices.
Each
device
in the list must have the following fields in theproperties
section that affect how the device will be handled:wipe
(mandatory, boolean)Defines if the device must be wiped of the data before being used.
workBy
(optional, string)Defines how the device should be identified using a comma-separated string with the following values (in order of priority):
by_id,by_path,by_name,by_wwn
.
softRaidDevices
Tech PreviewList of definitions of a software-based Redundant Array of Independent Disks (RAID) created by mdadm. Use the following fields to describe an mdadm RAID device:
name
(mandatory, string)Name of a RAID device. Supports the following formats:
dev
path, for example,/dev/md0
.simple name, for example,
raid-name
that will be created as/dev/md/raid-name
on the target OS.
devices
(mandatory, list)List of partitions from the
devices
list. Expand the resulting list of devices into at least two partitions.
level
(optional, string)Level of a RAID device, defaults to
raid1
. Possible values:raid1
,raid0
,raid10
.
metadata
(optional, string)Metadata version of RAID, defaults to
1.0
. Possible values:1.0
,1.1
,1.2
. For details about the differences in metadata, see man 8 mdadm.Warning
The EFI system partition
partflags: ['esp']
must be a physical partition in the main partition table of the disk, not under LVM or mdadm software RAID.
fileSystems
List of file systems. Each file system can be created on top of either device, partition, or logical volume. If more file systems are required for additional devices, define them in this field.
logicalVolumes
List of LVM logical volumes. Every logical volume belongs to a volume group from the
volumeGroups
list and has thesize
attribute for a size in the corresponding units.You can also add a software-based RAID
raid1
created by LVM using the following fields:name
Name of a logical volume.
type
Type of a logical volume. If you require a usual logical volume, you can omit this field.
Possible values:
linear
Default. A usual logical volume. This value is implied for bare metal host profiles created using the Container Cloud release earlier than 2.12.0 where the
type
field is unavailable.
raid1
Tech PreviewServes to build the
raid1
type of LVM. Equals to the lvcreate --type raid1... command. For details, see man 8 lvcreate and man 7 lvmraid.
vg
Name of a volume group. Must be a name from the
volumeGroups
list.
sizeGiB
(orsize
Available since 2.20.0)Size of a logical volume in gigabytes. When set to
0
, all available space on the corresponding volume group will be used. The0
value equals-l 100%FREE
in the lvcreate command.Caution
Mirantis recommends using only one parameter name type and units throughout the configuration files. If both
sizeGiB
andsize
are used,sizeGiB
is ignored during deployment and the suffix is adjusted accordingly. For example,1.5Gi
will be serialized as1536Mi
. The size without units is counted in bytes. For example,size: 120
means 120 bytes.
volumeGroups
List of definitions of LVM volume groups. Each volume group contains one or more devices or partitions from the
devices
list.
preDeployScript
Shell script that executes on a host before provisioning the target operating system inside the
ramfs
system.
postDeployScript
Shell script that executes on a host after deploying the operating system inside the
ramfs
system that is chrooted to the target operating system. To use a specific default gateway (for example, to have Internet access) on this stage, refer to Override the default dnsmasq settings.
grubConfig
List of options passed to the Linux GRUB bootloader. Each string in the list defines one parameter.
kernelParameters:sysctl
List of kernel sysctl options passed to
/etc/sysctl.d/999-baremetal.conf
during abmh
provisioning. For the list of options prohibited to change, refer to MKE documentation: Set up kernel default protections.Note
If asymmetric traffic is expected on some of the managed cluster nodes, enable the loose mode for the corresponding interfaces on those nodes by setting the
net.ipv4.conf.<interface-name>.rp_filter
parameter to"2"
in thekernelParameters.sysctl
section. For example:kernelParameters: sysctl: net.ipv4.conf.k8s-lcm.rp_filter: "2"
kernelParameters:modules
List of kernel modules options passed to
/etc/modprobe.d/{filename}
during abmh
provisioning.
Configuration example:
spec:
devices:
- device:
wipe: true
partitions:
- dev: ""
name: bios_grub
partflags:
- bios_grub
size: 4Mi
...
- device:
wipe: true
partitions:
- dev: ""
name: lvm_lvp_part
softRaidDevices:
- name: root
level: raid1 ## <-- MD raid1
devices:
- partition: root_part1
- partition: root_part2
- name: raid-name
level: raid0 ## <-- MD raid0
devices:
- partition: rest_sda
- partition: rest_sdb
logicalVolumes:
- name: root
type: raid1 ## <-- LVM raid1
vg: vg-root
size: 39.9Gi
- name: data
type: linear
vg: vg-data
size: 0
fileSystems:
- fileSystem: vfat
partition: config-2
- fileSystem: vfat
mountPoint: /boot/efi
partition: uefi
...
- fileSystem: ext4
logicalVolume: lvp
mountPoint: /mnt/local-volumes/
logicalVolumes:
- name: root
size: 0
vg: lvm_root
- name: lvp
size: 0
vg: lvm_lvp
postDeployScript: |
#!/bin/bash -ex
echo $(date) 'post_deploy_script done' >> /root/post_deploy_done
preDeployScript: |
#!/bin/bash -ex
echo 'ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"' > /etc/udev/rules.d/60-ssd-scheduler.rules
echo $(date) 'pre_deploy_script done' >> /root/pre_deploy_done
volumeGroups:
- devices:
- partition: lvm_root_part
name: lvm_root
- devices:
- partition: lvm_lvp_part
name: lvm_lvp
grubConfig:
defaultGrubOptions:
- GRUB_DISABLE_RECOVERY="true"
- GRUB_PRELOAD_MODULES=lvm
- GRUB_TIMEOUT=20
kernelParameters:
sysctl:
# For the list of options prohibited to change, refer to
# https://docs.mirantis.com/mke/3.6/install/predeployment/set-up-kernel-default-protections.html
kernel.dmesg_restrict: "1"
kernel.core_uses_pid: "1"
fs.file-max: "9223372036854775807"
fs.aio-max-nr: "1048576"
fs.inotify.max_user_instances: "4096"
vm.max_map_count: "262144"
modules:
- filename: kvm_intel.conf
content: |
options kvm_intel nested=1