Public bug reported: cloud-init running in ubuntu jammy-server-cloudimg-amd64-disk-kvm.img does not detect NoCloud cidata ISO in a qemu VM that uses emulated SATA cdrom drive.
SATA is the default used by qemu's -M q35 machine type, which is the preferred modern config over the default `-M pc` machine type, which uses IDE. Using -M pc and therefore IDE _does_ work. Using the the non-KVM image also _does_ work (jammy-server-cloudimg- amd64.img) Debugging this a bit showed that cloud-init `ds-identify --force` correctly finds the ISO once I've logged in, but not at boot up, I think because the sata cdrom is discovered by udev too late. This also affects ubuntu20.04 cloud images similarly: -disk-kvm is busted, other image is fine. Maybe it's an initrd driver issue, or issue with bits being modularized when they shouldn't, not sure. Here's the loaded driver difference for -M pc and -M q35 with -kvm-disk.img root@ubuntu:~# diff -rup pc q35 --- pc 2022-02-22 19:25:11.731067208 +0000 +++ q35 2022-02-22 19:26:55.749459099 +0000 @@ -7,7 +7,8 @@ loop 28672 6 dm_multipath 24576 0 dm_mod 86016 3 dm_multipath kvm_intel 200704 0 -pata_acpi 12288 0 +ahci 36864 0 +libahci 24576 1 ahci fuse 106496 1 configfs 32768 1 ip_tables 24576 0 Some background: I'm upstream virt-manager/virt-install dev. virt-install provides a `--cloud-init` option where we attach a NoCloud formatted ISO. A user reported this doesn't work out of the box with ubuntu20.04 -kvm-disk.img: https://github.com/virt-manager/virt-manager/issues/359 This isn't virt-install --cloud-init specific, see this report which pointed me towards the -kvm-disk difference: https://stackoverflow.com/questions/68512432/cannot-login-to-vm-using- qemu-nocloud-cloud-init-on-macos-with-ubuntu-cloud-imag Though virt-install users are kinda more likely to hit this since we increasingly default to q35. If users are just testing with qemu-kvm directly without specifying -machine q35, they won't hit this. Reproducer with virt-install: git clone https://github.com/virt-manager/virt-manager cd virt-manager wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-disk-kvm.img ./virt-install --osinfo ubuntu20.04 --disk jammy-server-cloudimg-amd64-disk-kvm.img --cloud-init ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1961832 Title: jammy-server-cloudimg-amd64-disk-kvm.img NoCloud data source not detected with qemu SATA cdrom Status in cloud-init: New Bug description: cloud-init running in ubuntu jammy-server-cloudimg-amd64-disk-kvm.img does not detect NoCloud cidata ISO in a qemu VM that uses emulated SATA cdrom drive. SATA is the default used by qemu's -M q35 machine type, which is the preferred modern config over the default `-M pc` machine type, which uses IDE. Using -M pc and therefore IDE _does_ work. Using the the non-KVM image also _does_ work (jammy-server-cloudimg- amd64.img) Debugging this a bit showed that cloud-init `ds-identify --force` correctly finds the ISO once I've logged in, but not at boot up, I think because the sata cdrom is discovered by udev too late. This also affects ubuntu20.04 cloud images similarly: -disk-kvm is busted, other image is fine. Maybe it's an initrd driver issue, or issue with bits being modularized when they shouldn't, not sure. Here's the loaded driver difference for -M pc and -M q35 with -kvm-disk.img root@ubuntu:~# diff -rup pc q35 --- pc 2022-02-22 19:25:11.731067208 +0000 +++ q35 2022-02-22 19:26:55.749459099 +0000 @@ -7,7 +7,8 @@ loop 28672 6 dm_multipath 24576 0 dm_mod 86016 3 dm_multipath kvm_intel 200704 0 -pata_acpi 12288 0 +ahci 36864 0 +libahci 24576 1 ahci fuse 106496 1 configfs 32768 1 ip_tables 24576 0 Some background: I'm upstream virt-manager/virt-install dev. virt-install provides a `--cloud-init` option where we attach a NoCloud formatted ISO. A user reported this doesn't work out of the box with ubuntu20.04 -kvm-disk.img: https://github.com/virt-manager/virt-manager/issues/359 This isn't virt-install --cloud-init specific, see this report which pointed me towards the -kvm-disk difference: https://stackoverflow.com/questions/68512432/cannot-login-to-vm-using- qemu-nocloud-cloud-init-on-macos-with-ubuntu-cloud-imag Though virt-install users are kinda more likely to hit this since we increasingly default to q35. If users are just testing with qemu-kvm directly without specifying -machine q35, they won't hit this. Reproducer with virt-install: git clone https://github.com/virt-manager/virt-manager cd virt-manager wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-disk-kvm.img ./virt-install --osinfo ubuntu20.04 --disk jammy-server-cloudimg-amd64-disk-kvm.img --cloud-init To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1961832/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
