yahoo-eng-team team mailing list archive

[Cole Robinson <1961832@xxxxxxxxxxxxxxxxxx>]

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