The process I have been using up to now, has been to download the generic cloud images from various Linux Distro sites (CentOS, now Rocky). These images are pre-baked for clouds, meaning that they're smaller, more efficient, and they generally have cloud packages installed on them (i.e. cloud-init).
It is easier (and more efficient) to use one of these images, in my thinking, than to try and take an ISO and build an image "from scratch".
The problem, though, is that "cloud images" are generally public cloud images: AWS, Azure, GKE, et al. If you are running your own private cloud on VMware, you will run into problems using these cloud images.
Today, I am having issues with the Rocky 9.5 generic cloud image.
I am downloading the qcow2, using qemu-img convert to convert qcow2 to vmdk, then running ovftool using a templatized template.vmx file. Everything works fine, but when I load the image into our CMP which initializes with cloud-init, the VM is booting up fine, but no cloud-init is running, so you cannot log into the VM.
Here is the template.vmx.parameterized file I am using. I use sed to replace the parameters, then the file is renamed template.vmx before running ovftool on it.
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "11"
vmci0.present = "TRUE"
floppy0.present = "FALSE"
svga.vramSize = "16777216"
tools.upgrade.policy = "manual"
sched.cpu.units = "mhz"
sched.cpu.affinity = "all"
scsi0.virtualDev = "lsilogic"
scsi0.present = "TRUE"
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.fileName = "PARM_VMDK"
sched.scsi0:0.shares = "normal"
sched.scsi0:0.throughputCap = "off"
scsi0:0.present = "TRUE"
ide0:0.present ="true"
ide0:0.startConnected = "TRUE"
ide0:0.fileName = "/opt/images/nfvcloud/imagegen/rocky9/cloudinit.iso"
ide0:0.deviceType = "cdrom-image"
displayName = "PARM_DISPLAYNAME"
guestOS = "PARM_GUESTOS"
vcpu.hotadd = "TRUE"
mem.hotadd = "TRUE"
bios.hddOrder = "scsi0:0"
bios.bootOrder = "cdrom,hdd"
sched.cpu.latencySensitivity = "normal"
svga.present = "TRUE"
RemoteDisplay.vnc.enabled = "FALSE"
RemoteDisplay.vnc.keymap = "us"
monitor.phys_bits_used = "42"
softPowerOff = "TRUE"
sched.cpu.min = "0"
sched.cpu.shares = "normal"
sched.mem.shares = "normal"
sched.mem.minsize = "1024"
memsize = "PARM_MEMSIZE"
migrate.encryptionMode = "opportunistic"I have tried using cdrom,hdd and just hdd on the boot order. Neither makes a difference.
When I run the ovftool program, it generates the following files, which look correct.
Rocky-9-5-GenericCloud-LVM-disk1.vmdk
Rocky-9-5-GenericCloud-LVM-file1.iso
Rocky-9-5-GenericCloud-LVM.mf
Rocky-9-5-GenericCloud-LVM.ovf
The ovf file, I have inspected. It does have references to both the vmdk and iso file in it, as it should.
The iso file, I ran a utility on it and it seems to look okay also. The two directories user_data and meta_data seem to be on there as they should be.
$ isoinfo -i Rocky-9-5-GenericCloud-LVM-file1.iso -l
Directory listing of /
d--------- 0 0 0 2048 Dec 18 2024 [ 28 02] .
d--------- 0 0 0 2048 Dec 18 2024 [ 28 02] ..
d--------- 0 0 0 2048 Dec 18 2024 [ 30 02] META_DAT
d--------- 0 0 0 2048 Dec 18 2024 [ 29 02] USER_DAT
Directory listing of /META_DAT/
d--------- 0 0 0 2048 Dec 18 2024 [ 30 02] .
d--------- 0 0 0 2048 Dec 18 2024 [ 28 02] ..
Directory listing of /USER_DAT/
d--------- 0 0 0 2048 Dec 18 2024 [ 29 02] .
d--------- 0 0 0 2048 Dec 18 2024 [ 28 02] ..This Rocky generic cloud image, it does NOT have VMware Tools (open-vm-tools package) installed on it - I checked into that. But you shouldn't need VMware Tools for cloud-init to initialize properly.
I am perplexed as to why cloud-init won't load properly, and I am about to drop kick this image and consider alternative ways of generating an image for this platform. I don't understand why these images work fine on public clouds, but not VMware.
I may need to abandon this generic cloud image altogether and use another process. I am going to examine this Packer process.
https://docs.rockylinux.org/guides/automation/templates-automation-packer-vsphere/
No comments:
Post a Comment