identify openstack kvm platform on ppc64

[Scott Moser]

On i386 and amd64, openstack puts 'OpenStack Nova', into the dmi platform
information. OpenStack using kvm on ppc64el or ppc64, does not identify itself to the guest in any way.

The result is that cloud-init cannot identify it is running on openstack.

We need two things
 a.) change openstack to provide that information through libvirt on ppc64
     in some way.
 b.) possibly changes in qemu to pass information through that the guest
     can see. Some options here might include putting information in
     the device tree or possibly on the attached disk (model of the disk could be 'OpenStack disk XXXX').

Related bugs:
 bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
 https://bugs.launchpad.net/cloud-init/+bugs?field.tag=dsid-nova

[Matt Riedemann (mriedem)]

Is there something that nova needs to do here? That's not clear to me.

[Mikhail S Medvedev (msmedved)]

Matt, maybe from the side of nova there could be an argument added to qemu that would pass the field that cloud-init wants? That is, other than through smbios arguments.

[Sylvain Bauza (sylvain-bauza)]

Well, the guest shouldn't know which hypervisor type it's running IMHO. That looks like a security concern at least.

That said, it could be possible for operators explicitely wanting to pass that information to their guest OS that they use cloud-init for sure, but that doesn't look like something Nova would support IMHO.

[Sylvain Bauza (sylvain-bauza)]

Just to be clear, either way, that wouldn't look like a bug from the Nova perspective, rather a new possibility to inform the guest and that would probably need at least a blueprint for describing the new feature

https://docs.openstack.org/developer/nova/process.html#how-do-i-get-my-code-merged

[Scott Moser (smoser)]

Sorry I was short on background information

Openstack Nova (libvirt) on i386 and amd64 arch already does this. This bug is specifically for ppc64 lacking what x86 already does.

(For info on how this is done see https://bugs.launchpad.net/cloud-init/+bug/1661693/comments/2)

ppc64 hardware (and qemu) does not have DMI data, so an exact copy of the implementation is not possible.

It is possible we do need a qemu function added. I am looking to some ppc64 experts to get more information on whether we could have openstack utilize an existing function or if we would need feature added to qemu first.

[Rafael Folco (rafaelfolco)]

Some observations:

- DMTF defined an "End of Life" process for DMI, which ended on March 31, 2005. Using it extensively on x86 doesn't make it right thing to do, or to follow.

- lshw has most of the information that dmidecode provides. It does not report a cloud instance with "OpenStack Nova" string as dmi does in the product_name field, though:
    $ cat /sys/class/dmi/id/product_name
    OpenStack Nova

- qemu (ppc64le) does not have an equivalent to -smbios.

- Ideally, this should be implemented as service through virtio-vsock, a host/guest communications device. Technically doable, a qemu ppc dev said.

- As a placeholder until this is not addressed in qemu, IMHO, lshw could be used to detect KVM ppc guests:
    description: Computer
    product: IBM pSeries (emulated by qemu)
    <...>

[Thierry Carrez (ttx)]

Beyond the bug vs. feature discussion (or which technical solution would be used to expose that information under ppc64) there is the question of whether exposing to the guest that it is running in a Nova-provided instance is desirable or not. In comment #3 Sylvain hints that it may create security concerns. As all security questions this is likely a trade-off, so we need to know what convenience we gain by leaking that extra information.

Scott: I suspect you want a reliable source of information so that cloud-init can be sure it's running under OpenStack before triggering some provider-specific actions ? What kind of actions would that be ?

[Scott Moser (smoser)]

Thierry, you're right. I'd like the platform to identify itself to the guest. And openstack already does this in libvirt/kvm and i386/x86_64 (which I suggest is by far the most common deployment path).

In order to create cross cloud-platform images there has to be some way to determine where an image is running, so it can behave appropriately for the platform.

Essentially, we have a communication mechanism in smbios/dmi where by the host says "You're running on OpenStack". Once that bit of information is established, cloud-init can then decide to reach the metadata service that openstack provides (http://169.254.169.254/openstack/).

Without the identification from the host, poking/polling at this network service can be problematic for many reasons.

[Thierry Carrez (ttx)]

Scott: that sounds reasonable...

Sylvain: any reason to think that leaking that information to the host would create security issues ? I bet there are plenty of creative ways to determine that a host is running on an OpenStack cloud already...

[Scott Moser (smoser)]

As an example of one such "creative" way to determine that a host is OpenStack:
  wget http://196.254.169.254/openstack/

Ie, openstack by-design identifies itself to guests. Even if you didn't have a metadata service, you'd have a config drive.

[Markus Zoeller (markus_z) (mzoeller)]

IBM s390x guy here, `dmi` doesn't work for us either. Nevertheless how to resolve this, did I understand it correctly that the fallback is the "old" way, "polling until something works"?
Bug 1669675 describes this behavior:

    "If no result is found, keep cloud-init enabled.
     cloud-init will search its normal list and issue
     warnings."

[Andreas Scheuring (andreas-scheuring)]

What about appending something to the kernels command line instead of using smbios and/or dmi? For containers the commandline is considered as well (PID_1_PLATFORM), so why not for VMs as well?

[Andreas Scheuring (andreas-scheuring)]

Seems like that libvirts cmdline argument is just for direct kernel boot [1]. So not an option...

[1] https://libvirt.org/formatdomain.html#elementsOSKernel

[Scott Moser (smoser)]

Markus,

Currently for non-x86 systems cloud-init falls back to looking polling for network metadata services. We'd like to fix that and make non-x86 consistent with x86. But until we can fix this bug, we can't really do that.

Andreas, As you found, kernel command line is really not ideal at all, as modification from "outside" is not really possible. We want to enable vendors to make images that "just work" on multiple clouds. Requiring the image consumer to open the image and modify the kernel command line would break that.

We really need the cloud platform to identify itself to the running system in a deterministic way.

[Scott Moser (smoser)]

Markus,
I removed the s390x tag from this bug and filed one for that at
 https://bugs.launchpad.net/nova/+bug/1693524

I've also tagged these "identify openstack" bugs with dsid-nova.
https://bugs.launchpad.net/cloud-init/+bugs?field.tag=dsid-nova

The reason for having one per arch is that they're likely to just use different mechanisms.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2804