Bug 1464182
Summary: | openstack-nova: unable to launch an instance: InternalError: Unable to get host UUID: /etc/machine-id is empty | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Alexander Chuzhoy <sasha> | ||||
Component: | openstack-nova | Assignee: | Martin André <m.andre> | ||||
Status: | CLOSED WORKSFORME | QA Contact: | Alexander Chuzhoy <sasha> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | urgent | ||||||
Version: | 12.0 (Pike) | CC: | berrange, dasmith, eglynn, kchamart, m.andre, ohochman, sbauza, sferdjao, sgordon, srevivo, tvignaud, vromanso | ||||
Target Milestone: | rc | Keywords: | Triaged | ||||
Target Release: | 12.0 (Pike) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2017-08-31 16:16:56 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Alexander Chuzhoy
2017-06-22 15:10:12 UTC
Created attachment 1290755 [details]
/var/log/containers/nova/nova-compute.log
On compute node: [root@compute-0 ~]# cat /etc/machine-id 270d5597e0414f018ba9787924d7626b [root@compute-0 ~]# docker exec -it nova_libvirt bash tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified On container: ()[root@compute-0 /]# cat /etc/machine-id ()[root@compute-0 /]# Was able to w/a this issue by placing a string in /etc/machine-id on the nova_compute container. It was the same string taken from the compute host. openstack-base-docker:2017-06-21.5 also has an empty /etc/machine-id file. We need to first figure out what *exactly* Nova is using the `/etc/machine-id` for. So far, we can see that Docker is creating the /etc/machine-id, looking at this bug (thanks to Ollie Walsh for the pointer): https://bugzilla.redhat.com/show_bug.cgi?id=1130498 Ollie Walsh says this should probably be fixed in base RHEL / CentOS images. As the base CentOS / RHEL images have a 0 byte 'machine-id'. --- The official systemd documentation says, the `systemd-machine-id-setup` needs to be used to initialize the 'machine-id': https://www.freedesktop.org/software/systemd/man/systemd-machine-id-setup.html Also, from documentation of `machine-id(5)`: "This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one" (In reply to Kashyap Chamarthy from comment #5) > We need to first figure out what *exactly* Nova is using the > `/etc/machine-id` for. So, looking at the code (nova/virt/libvirt/driver.py), these two methods _get_host_sysinfo_serial_os(), and _get_host_sysinfo_serial_auto() use /etc/machine-id. Nova uses it (/etc/machine-id) for the 'sysinfo_serial' config attribute to the populate the host "serial" 'UUID exposed to guest in the virtual BIOS. Permitted options are "hardware", "os", "none" or "auto" (default): [...] cfg.StrOpt('sysinfo_serial', default='auto', choices=('none', 'os', 'hardware', 'auto'), help='The data source used to the populate the host "serial" ' 'UUID exposed to guest in the virtual BIOS.'), [...] do we need to mount this file from the compute-node to the container? taking it back to container DFG, as the solution might be to remove this file from the container during prep , and it would recreate with the right content. The issue doesn't reproduce and I'm able to launch instances although the machine-id file is empty on container: [root@overcloud-compute-0 ~]# cat /etc/machine-id f18324a2198a4534bb27b9d3af207b16 [root@overcloud-compute-0 ~]# docker exec -u root -it nova_libvirt bash tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified ()[root@overcloud-compute-0 /]# cat /etc/machine-id ()[root@overcloud-compute-0 /]# Closing the bug. |