Oracle Cloud Infrastructure allows customers to import external custom images; however, most of these images are originally built for environments that boot from local disks or use paravirtualized storage. While this works well for virtual machines, bare metal provisioning in OCI follows a different boot model and therefore requires additional preparation.
Why External Images Often Fail on Bare Metal
When an external image is imported into OCI and launched on a bare metal shape without modification, one or more of the following issues commonly occur:
The instance fails to complete the boot process
The operating system cannot locate the root filesystem
Network interfaces are not initialized during early boot
These behaviors are not platform defects. They indicate that the image lacks specific prerequisites required for bare metal booting in OCI.
Once these requirements are understood, the remediation is straightforward and enables the use of a single image across both virtual machine and bare metal instances.
Key Areas to Address for Image Compatibility
To ensure that one custom image works reliably across all OCI compute shapes, focus on the following three core areas.
1. Enable iSCSI Boot Support
Bare metal instances in OCI boot from network-attached storage using iSCSI. The operating system image must therefore support iSCSI during the earliest stages of the boot process.
At a minimum, the image should include:
Installation of the iSCSI initiator utilities (for example,
iscsi-initiator-utils)Required kernel parameters:
rd.iscsi.ibft=1rd.iscsi.firmware=1
A rebuilt
initramfsthat incorporates iSCSI and networking support
With these elements in place, the operating system can:
Discover the boot volume presented by OCI
Initialize networking early enough to access the volume
Mount the root filesystem and continue the boot sequence
This configuration does not affect virtual machines, allowing the same disk layout to function on both VM and bare metal shapes.
2. Align Cloud-Init with OCI Requirements
Cloud-init is responsible for essential first-boot activities, including:
Applying SSH keys from instance metadata
Configuring network interfaces
Processing custom initialization scripts
External images frequently include outdated or incompatible cloud-init versions designed for other cloud platforms. For reliable operation in OCI, the image must:
Include cloud-init version 20.3 or later, which supports OCI as a data source
Remove or replace older cloud-init packages that may conflict
Configure Oracle Cloud Infrastructure as the authoritative metadata source
Once properly aligned, both virtual machine and bare metal instances initialize consistently and predictably.
3. Clean the Image Before Capture
Before converting the configured system into a reusable custom image, the operating system should be cleaned to remove residual state. This step prevents subtle and difficult-to-diagnose issues during future provisioning.
Recommended cleanup actions include:
Clearing cloud-init state and logs using
cloud-init clean --logsRemoving old log files and temporary data
The objective is to ensure that every instance launched from the image behaves as a fresh deployment, regardless of the compute shape.
Summary
By enabling iSCSI boot support, ensuring cloud-init compatibility with OCI, and properly cleaning the image before capture, organizations can successfully reuse a single external custom image across both virtual machine and bare metal instances in Oracle Cloud Infrastructure. This approach reduces image sprawl, improves consistency, and simplifies operations across hybrid and cloud-native environments.
No comments:
Post a Comment