1. The cloud-init generator stage, through the systemd service, determines whether to run cloud-init upon the boot.
2. During the local stage, cloud-init finds local datasources and applies network configuration.
3. During the network stage, cloud-init processes user data and runs the modules listed under cloud_init_modules in your cloud.cfg file. You can enable, disable, or add modules to the cloud_init_modules section.
4. During the config stage, cloud-init runs the modules listed under cloud_config_modules in your cloud.cfg file. You can enable, disable, or add modules to the cloud_config_modules section.
5. During the final stage, cloud-init can run what you have included under cloud_final_modules in your cloud.cfg file. You can include package installations that you would typically run after a system boots and can also include configuration management plug-ins and user scripts. You can enable, disable, or add modules to the cloud_final_modules section.

1. The network phase (cloud_init_modules)
2. The configuration phase (cloud_config_modules)
3. The final phase (cloud_final_modules)

Procedure

1. Create a directory named cloudinitiso and move into it.

   $ mkdir cloudinitiso
   $ cd cloudinitiso

2. Create a file named meta-data. Add the following information to the file.

   instance-id: citest
   local-hostname: citest-1

3. Create a file named user-data. Include the following information in the file.

   #cloud-config
   password: cilogon
   chpasswd: {expire: False}
   ssh_pwauth: True
   ssh_authorized_keys:
     - ssh-rsa AAA...fhHQ== sample@redhat.com

   Note

   The final line of the user-data file references an SSH public key. Find your SSH public keys in ~/.ssh/id_rsa.pub. When trying this sample procedure, modify the line to include one of your public keys.

4. Use the genisoimage command to create an ISO image that includes user-data and meta-data.

   # genisoimage -output ciiso.iso -volid cidata -joliet -rock user-data meta-data
   
   I: -input-charset not specified, using utf-8 (detected in locale settings)
   Total translation table size: 0
   Total rockridge attributes bytes: 331
   Total directory bytes: 0
   Path table size(bytes): 10
   Max brk space used 0
   183 extents written (0 MB)

5. Download a KVM Guest Image from the Red Hat Customer Portal to the /var/lib/libvirt/images directory.

6. Create a new VM from the KVM Guest Image using the virt-install command. Include the ISO image you created as an attachment to the image.

   virt-install \
       --memory 4096 \
       --vcpus 4 \
       --name mytestcivm \
       --disk /var/lib/libvirt/images/rhel-8.1-x86_64-kvm.qcow2,device=disk,bus=virtio,format=qcow2 \
       --disk /home/sample/cloudinitiso/ciiso.iso,device=cdrom \
       --os-type Linux \
       --os-variant rhel9.0 \
       --virt-type kvm \
       --graphics none \
       --import

7. Log on to your image as cloud-user. Your password is cilogon.

   citest-1 login: cloud-user
   Password:
   [cloud-user@citest-1 ~]$

Procedure

1. Depending upon the requirements of your datasource, open your user-data file for editing, or otherwise add the following directive to the cloud.cfg.d directory.

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Change the line chpasswd: {expire: False} to chpasswd: {expire: True}.

   #cloud-config
   password: mypassword
   chpasswd: {expire: True}
   ssh_pwauth: True
   ssh_authorized_keys:
     - ssh-rsa AAA...SDvz user1@yourdomain.com
     - ssh-rsa AAB...QTuo user2@yourdomain.com

   This works to expire the password because password and chpasswd operate on the default user unless you indicate otherwise.

   Note

   This is a global setting. When you set chpasswd to True, all users you create need to change their passwords when they log in.

Procedure

1. Depending upon the requirements of your datasource, open your user-data file for editing, or otherwise add the following directive to the cloud.cfg.d directory.

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add the line user: <username>, replacing <username> with the new default user name.

   #cloud-config
   user: username
   password: mypassword
   chpasswd: {expire: False}
   ssh_pwauth: True
   ssh_authorized_keys:
     - ssh-rsa AAA...SDvz user1@yourdomain.com
     - ssh-rsa AAB...QTuo user2@yourdomain.com

Procedure

1. Depending upon the requirements of your datasource, open your user-data file for editing, or otherwise add the following directive to the cloud.cfg.d directory.

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Create a user list in the chpasswd section of the file. The format is shown in the following sample.

   Note

   White space is significant. Do not include white space before or after the colon in your user list. If you include white space, the password is set with a space in it.

   #cloud-config
   ssh_pwauth: True
   ssh_authorized_keys:
     - ssh-rsa AAA...SDvz user1@yourdomain.com
     - ssh-rsa AAB...QTuo user2@yourdomain.com
   chpasswd:
     list: |
        root:myrootpassword
        cloud-user:mypassword
     expire: False

   Note

   If you use this method to set the user password, you must set all passwords in this section.

Procedure

1. Depending upon the requirements of your datasource, open your user-data file for editing, or otherwise add the following directive to the cloud.cfg.d directory.

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add or modify the users section to add users.

   • If you want cloud-user to be the default user created along with the other users you specify, ensure that you add default as the first entry in the section. If it is not the first entry, cloud-user is not created.

   • By default, users are labeled as unconfined_u if there is not an selinux-user value.

     #cloud-config
     users:
       - default
       - name: user2
         gecos: User N. Ame
         selinux-user: staff_u
         groups: users,wheel
         ssh_pwauth: True
         ssh_authorized_keys:
           - ssh-rsa AA..vz user@domain.com
     chpasswd:
       list: |
         root:password
         cloud-user:mypassword
         user2:mypassword2
       expire: False

     Note

     • The example places the user user2 into two groups, users and wheel.

Procedure

1. Depending upon the requirements of your datasource, open your user-data file for editing, or otherwise add the following directive to the cloud.cfg.d directory.

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add the sections for bootcmd and runcmd; include commands you want cloud-init to execute.

   #cloud-config
   users:
     - default
     - name: user2
       gecos: User N. Ame
       groups: users
   chpasswd:
     list: |
       root:password
       fedora:myfedpassword
       user2:mypassword2
     expire: False
   bootcmd:
    - echo New MOTD >> /etc/motd
   runcmd:
    - echo New MOTD2 >> /etc/motd

Procedure

1. Depending upon the requirements of your datasource, open your user-data file for editing, or otherwise add the following directive to the cloud.cfg.d directory.

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add a sudo entry and specify the user access. For example, sudo: ALL=(ALL) NOPASSWD:ALL allows a user unrestricted user access.

3. Add a groups entry and specify the groups that include the user.

   #cloud-config
   users:
     - default
     - name: user2
       gecos: User D. Two
       sudo: ["ALL=(ALL) NOPASSWD:ALL"]
       groups: wheel,adm,systemd-journal
       ssh_pwauth: True
       ssh_authorized_keys:
         - ssh-rsa AA...vz user@domain.com
   chpasswd:
     list: |
       root:password
       cloud-user:mypassword
       user2:mypassword2
     expire: False

1. Depending upon the requirements of your datasource, open your user-data file for editing, or otherwise add the following directive to the cloud.cfg.d directory.

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add a network-interfaces section.

   network-interfaces: |
     iface eth0 inet static
     address 192.168.1.10
     network 192.168.1.0
     netmask 255.255.255.0
     broadcast 192.168.1.255
     gateway 192.168.1.254
   bootcmd:
     - ifdown eth0
     - ifup eth0

Procedure

1. Depending upon the requirements of your datasource, open your user-data file for editing, or otherwise add the following directive to the cloud.cfg.d directory.

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Create an entry for the user root in the users section.

   The simple example that follows includes a users section with only the name option.

   users:
     - name: root
   chpasswd:
     list: |
       root:password
     expire: False

3. Optionally, set up SSH keys for the root user.

   users:
     - name: root
       ssh_pwauth: True
       ssh_authorized_keys:
         - ssh-rsa AA..vz user@domain.com

Procedure

1. Depending upon the requirements of your datasource, open your user-data file for editing, or otherwise add the following directive to the cloud.cfg.d directory.

   Note

   All user directives include #cloud-config at the top of the file so that cloud-init recognizes the file as containing user directives. When you include directives in the cloud.cfg.d directory, name the file *.cfg, and always include #cloud-config at the top of the file.

2. Add or modify the write_files module to include the path to the container-storage-setup utility.

   The following example sets the size of the root logical volume to 6GB rather than the default 3GB.

   write_files:
     - path: /etc/sysconfig/docker-storage-setup
       permissions: 0644
       owner: root
       content: |
       ROOT_SIZE=6G

   Note

   Prior to RHEL 7.4, container-storage-setup was called docker-storage-setup. If you are using OverlayFS for storage, as of RHEL 7.4 you can now use that type of file system with SELinux in enforcing mode.

Procedure

1. Depending upon the requirements of your datasource, open your meta-data file for editing, or otherwise add the following directive to the cloud.cfg file or the cloud.cfg.d directory.
2. Add the locale directive, specifying the location. The following sample sets the locale to ja_JP (Japan) with UTF-8 encoding.

Procedure

1. Open the /etc/cloud/cloud.cfg file for editing.

2. Comment out or remove the configuration that you do not want cloud-init to update when you restore your instance.

   For example, to avoid updating the SSH key file, remove -ssh from the cloud_init_modules section.

   cloud_init_modules:
    - disk_setup
    - migrator
    - bootcmd
    - write-files
    - growpart
    - resizefs
    - set_hostname
    - update_hostname
    - update_etc_hosts
    - rsyslog
    - users-groups
    # - ssh

Procedure

1. Log in to your VM.
2. Add or change directives, for example, modify the cloud.cfg file in the /etc/cloud directory or add directives to the /etc/cloud/cloud.cfg.d directory.

3. Run the cloud-init clean command to clean directories so that cloud-init can rerun. You can also run the following commands as root to clean the VM.

   `rm -Rf /var/lib/cloud/instances/*`
   `rm -Rf /var/lib/cloud/instance`
   `rm -Rf /var/lib/cloud/data/*`

   Note

   You can save the cleaned image as a new image and use that image for multiple VMs. The new VMs run cloud-init using your updated cloud-init configuration.

4. Rerun cloud-init or reboot the VM.

   cloud-init reruns, implementing the configuration changes you made.

Procedure

1. Create and launch an instance for the OpenStack Platform. Refer to Virtual Machine Instances for information on creating instances for OpenStack. In this example, our virtual machine includes cloud-init, which runs upon boot of the virtual machine.
2. Add or change directives. For example, modify the user-data.file file that is stored on the OpenStack HTTP server.

3. Clean the virtual machine. Run the following commands as root.

   `rm -rf /etc/resolv.conf /run/cloud-init`
   `userdel -rf cloud-user`
   `hostnamectl set-hostname localhost.localdomain`
   `rm /etc/NetworkManager/conf.d/99-cloud-init.conf`

   Note

   You can save the cleaned image as a new image and use that image for multiple virtual machines. The new virtual machines run cloud-init using your updated cloud-init configuration.

4. Rerun cloud-init or reboot the virtual machine.

   Cloud-init reruns, implementing the configuration changes you made.

Procedure

1. Review the cloud-init configuration files.

   1. Examine the /etc/cloud/cloud.cfg configuration file. Check which modules are included under cloud_init_modules, cloud_config_modules, and cloud_final_modules.
   2. Check directives (*.cfg files) in the /etc/cloud/cloud.cfg.d directory.

2. Review the /var/log/cloud-init.log and /var/log/cloud-init-output.log files for details on a specific issue. For example, if the issue was that the root partition was not automatically extended, check log messages for growpart. If the file system was not extended, check log messages for resizefs. For example:

   # grep resizefs /var/log/cloud-init.log

   Note

   growpart does not support LVM. If your root partition is based in LVM, the root partition is not automatically extended upon first boot.

3. Rerun cloud-init. Sample scenarios follow. Run commands as root.

   • Rerun cloud-init with only the init modules.

     /usr/bin/cloud-init -d init

   • Rerun cloud-init with all modules in your configuration.

     /usr/bin/cloud-init -d modules

   • Delete the cloud-init cache and force cloud-init to run after boot.

     rm -rf /var/lib/cloud/* && /usr/bin/cloud-init -d init

   • Run the following commands to clean directories and simulate a clean instance.

     rm -Rf /var/lib/cloud/instances/*
     rm -Rf /var/lib/cloud/instance
     rm -Rf /var/lib/cloud/data/*
     reboot

   • Run the following commands to rerun cloud-init.

     cloud-init init --local
     cloud-init init