Create Enrollment Images

Boot from Enrollment Images to join Machines to the meltcloud platform.

Prerequisites

A Network Profile, which every Enrollment Image needs: it is how a Machine reaches meltcloud while enrolling.

Create an Enrollment Image

1. Go to Enrollment Images → Create Enrollment Image
2. Configure the properties as desired:

Property	Description	Default	Can be changed after creation
Name	User defined name for the Enrollment Image	-	No
Expires at	Date when the Enrollment Image becomes invalid	in 1 Week	No
Install disk device	Path to the device (i.e. /dev/disk/by-path/pci-0000:00:17.0-ata-1) where the system should be installed to. Leave empty to auto-detect. Required if disk mirroring is enabled	Auto-detect	No
Disk mirroring	Whether the install disk is mirrored onto a second disk for redundancy	No	No
Mirror device	Path to the device used as the mirror. Required if disk mirroring is enabled, and must differ from the install disk device	-	No
Force overwrite disk if it contains unknown data	Whether the installation should proceed even if unknown data on the install disk is found	No	No
Network Profile	The Network Profile Machines use to reach meltcloud while enrolling. It also becomes their depot and operational profile (unless the Machine is pre-registered).	-	No
Allow download via insecure HTTP	Whether download over insecure HTTP is allowed (see explanation below)	No	No

3. Click Create.

Enrollment Images are created specifically for your organization, so their creation takes some time – after some minutes they are available for download.

Choosing Disk Devices

Avoid kernel name paths such as /dev/sda or /dev/vda. The kernel assigns them in discovery order, so they can change between boots, particularly on servers that mix SATA, SAS and boot-optimized storage (i.e. Dell BOSS) controllers (nvmes are usually fine).

Use /dev/disk/by-path/ paths instead. They are derived from the physical slot the disk is attached to and stay stable across reboots:

/dev/disk/by-path/pci-0000:00:17.0-ata-1

Because a by-path path describes the slot, it is identical on every server of the same hardware model. A homogeneous fleet can therefore be enrolled with a single Enrollment Image.

Alternatively, /dev/disk/by-id/ paths can be used. They identify a specific disk by its serial number, which makes them unique per server, so you need one Enrollment Image per Machine.

Auto-Detection

If you leave Install disk device empty, the install disk is auto-detected. This works only if Linux sees exactly one block device (i.e. a single attached disk, or a Dell BOSS RAID pair that shows up as one). Otherwise, specify the path explicitly.

Auto-Detection is not available with Disk mirroring, which needs to specify both disks explicitly.

Finding the Disk Paths

If you don't know the paths of your server's disks, create an Enrollment Image with a bogus install disk device path (i.e. /dev/disk/by-path/unknown) and boot the server from it. Enrollment fails, and the available disks and their paths are printed on the server's serial console and in the Enrollment Logs. Create a second Enrollment Image with the correct paths afterwards.

WARNING

Be aware that Enrollment Images contain a private key and their download URLs a secure token to download them. Make sure your transfer and store your artifacts securely and treat the download URLs as secrets.

Boot from the .iso

Once you've generated the image, you will want to attach it to your server to boot from it and enroll.

See the options to boot servers from an .iso.

Troubleshooting

Closely watch the Logs tab in your enrollment image while booting your server. It shows the enrollment process and encountered errors as they happen.

No Logs?

If no enrollment logs appear, your server is either:

• not booting from the ISO at all
• failing to boot the ISO or starting Linux
• cannot reach the Foundry connectivity-wise.

To check what's going on, access the server's serial console. If Linux was booted properly, you should see a TUI, where you can press Ctrl+S to drop to a shell which allows you to investigate further.

Enrollment fails on an IPAM Subnet

A Machine enrolling on an IPAM Subnet picks its own address and checks with an ARP probe that nothing already answers for it.

On a segment where the router answers ARP for every address (local-proxy-arp on Cisco and Arista, proxy-arp unrestricted on Junos) the probe cannot tell a free address from a taken one and enrollment does not get an address.

To work around this, give each Machine its own Enrollment Image with a Subnet that uses an IP Pool with a single allocatable address. The Machine will then use this IP address to enroll.

Terraform

Reference

resource "time_offset" "in_a_day" {
  offset_days = 1
}

resource "meltcloud_enrollment_image" "example" {
  name       = "my-image"
  expires_at = time_offset.in_a_day.rfc3339

  install_disk_device = "/dev/disk/by-path/pci-0000:00:17.0-ata-1"
  network_profile_id  = meltcloud_network_profile.single_untagged.id
}

# a mirrored install requires both disks to be named explicitly.
resource "meltcloud_enrollment_image" "mirrored" {
  name       = "my-mirrored-image"
  expires_at = time_offset.in_a_day.rfc3339

  install_disk_device        = "/dev/disk/by-path/pci-0000:00:17.0-ata-1"
  install_disk_mirror        = true
  install_disk_mirror_device = "/dev/disk/by-path/pci-0000:00:17.0-ata-2"
  network_profile_id         = meltcloud_network_profile.single_untagged.id
}