systemd: generate stable machine IDS for ARM KVM guests

[arnaldo2792]

Issue number:
#1493

Description of changes:

49c17f96 systemd: generate stable machine IDs for ARM KVM guests

Systemd doesn't recognize Amazon EC2 as a valid dmi vendor. The vendor is used to detect the virtualization type, which then is used to generate the machine ID. Since no dmi vendor is detected, systemd defaults to use the random machine ID generator, which results in a different machine ID after each boot. This patch extends the list of valid dmi vendors, and adds Amazon EC2 as a new vendor.

Testing done:

In k8s 1.19, ecs and dev aarch64/x86_64:

• Run systemctl status to check that no units were failing
• Reboot and check that journalctl --list-boots shows two entries
• Run nginx pod/task/container and successfully call curl http://localhost within the pod/task/container
• Run images with the systemd.log_level kernel parameter as debug to validate the correct virtualization type was selected for both XEN and KVM:

ECS

aarch64 (t4g.medium)

Apr 20 17:01:26 localhost systemd[1]: Found VM virtualization kvm
Apr 20 17:01:26 localhost systemd[1]: Detected virtualization kvm.
Apr 20 17:01:26 localhost systemd[1]: Detected architecture arm64.

x86_64

XEN (c4.large)

Apr 20 17:02:04 localhost systemd[1]: Virtualization Xen found in DMI (/sys/class/d
Apr 20 17:02:04 localhost systemd[1]: Virtualization XEN, found /sys/hypervisor/pro
Apr 20 17:02:04 localhost systemd[1]: Found VM virtualization xen
Apr 20 17:02:04 localhost systemd[1]: Detected virtualization xen.
Apr 20 17:02:04 localhost systemd[1]: Detected architecture x86-64.

KVM (m5.xlarge)

Apr 20 17:01:57 localhost systemd[1]: Virtualization Amazon EC2 found in DMI (/sys/
Apr 20 17:01:57 localhost systemd[1]: UML virtualization not found in /proc/cpuinfo
Apr 20 17:01:57 localhost systemd[1]: Virtualization found, CPUID=KVMKVMKVM
Apr 20 17:01:57 localhost systemd[1]: Found VM virtualization kvm
Apr 20 17:01:57 localhost systemd[1]: Detected virtualization kvm.
Apr 20 17:01:57 localhost systemd[1]: Detected architecture x86-64.
Apr 20 17:01:57 localhost systemd[1]: Detected first boot.

k8s 1.19

aarch64

Apr 20 00:46:10 localhost systemd[1]: Virtualization Amazon EC2 found in DMI (/sys/class/dmi/id/sys_vendor)
Apr 20 00:46:10 localhost systemd[1]: UML virtualization not found in /proc/cpuinfo.
Apr 20 00:46:10 localhost systemd[1]: No virtualization found in CPUID
Apr 20 00:46:10 localhost systemd[1]: Found VM virtualization kvm
Apr 20 00:46:10 localhost systemd[1]: Detected virtualization kvm.
Apr 20 00:46:10 localhost systemd[1]: Detected architecture arm64.

x86_64

XEN (c4.large)

Apr 20 16:55:32 localhost systemd[1]: Virtualization Xen found in DMI (/sys/class/dmi/id/sys_vendor)
Apr 20 16:55:32 localhost systemd[1]: Virtualization XEN, found /sys/hypervisor/properties/features with value 00000705, XENFEAT_dom0 (indicating the 'hardware domain')
Apr 20 16:55:32 localhost systemd[1]: Found VM virtualization xen
Apr 20 16:55:32 localhost systemd[1]: Detected virtualization xen.
Apr 20 16:55:32 localhost systemd[1]: Detected architecture x86-64.

KVM (m5.xlarge)

Apr 20 16:55:22 localhost systemd[1]: Virtualization Amazon EC2 found in DMI (/sys/class/dmi/id/sys_vendor)
Apr 20 16:55:22 localhost systemd[1]: UML virtualization not found in /proc/cpuinfo.
Apr 20 16:55:22 localhost systemd[1]: Virtualization found, CPUID=KVMKVMKVM
Apr 20 16:55:22 localhost systemd[1]: Found VM virtualization kvm
Apr 20 16:55:22 localhost systemd[1]: Detected virtualization kvm.
Apr 20 16:55:22 localhost systemd[1]: Detected architecture x86-64.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[webern]

Not sure if it is normal to add your "Signed-off-by" to the pre-existing patches?

[arnaldo2792]

@webern I didn't remove the previous signed offs, and since I modified the sequence in the patches, I think it would be ok?

[webern]

@webern I didn't remove the previous signed offs, and since I modified the sequence in the patches, I think it would be ok?

Yeah not sure about patch etiquette but I'm sure others have experience there.

Something's going on with CI: I think this may be the error

  #3 resolve image config for docker.io/docker/dockerfile:1.1.3-experimental
  #3 sha256:91634ee2000a6b16774475f8fdb3b59615257c0080c8e3925f32b6477446bb90
  #3 ERROR: rpc error: code = Unknown desc = open /home/ec2-user/.docker/.token_seed: permission denied

Edit: it's across all PRs.

[arnaldo2792]

• Removed unnecessary sign off comments in existing patches

[bcressey]

typo:

Suggested change

	vendor table, and maps it to `VIRTUALIZATION_KVM`, so that a consitent
	vendor table, and maps it to `VIRTUALIZATION_KVM`, so that a consistent

[arnaldo2792]

• Fixed typo in patch's commit message

[arnaldo2792]

• Fixed malformed patch

[arnaldo2792]

• Regenerated patches since I edited manually to remove the Sign-off lines and VIM messed up some of the formatting