From 3906a4f7c6280fc99ea3b039841d2fe8017449a6 Mon Sep 17 00:00:00 2001 From: Eric Fried Date: Thu, 4 Oct 2018 10:22:47 -0500 Subject: [PATCH] High Precision Event Timer (HPET) on x86 guests Support HPET for x86 guests in the libvirt driver. blueprint: support-hpet-on-guest Co-Authored-By: Chris Friesen Change-Id: I26c5f5386b99f88dcc7f6ea4629a61f93084b3e7 Signed-off-by: Jack Ding --- .../stein/approved/support-hpet-on-guest.rst | 219 ++++++++++++++++++ 1 file changed, 219 insertions(+) create mode 100644 specs/stein/approved/support-hpet-on-guest.rst diff --git a/specs/stein/approved/support-hpet-on-guest.rst b/specs/stein/approved/support-hpet-on-guest.rst new file mode 100644 index 000000000..138cb44b4 --- /dev/null +++ b/specs/stein/approved/support-hpet-on-guest.rst @@ -0,0 +1,219 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +======================================================= +Support High Precision Event Timer (HPET) on x86 guests +======================================================= + +https://blueprints.launchpad.net/nova/+spec/support-hpet-on-guest + +Problem description +=================== + +Use Cases +--------- + +As an end user looking to migrate an existing appliance to run in a cloud +environment I would like to be able to request a guest with HPET so that I can +share common code between my virtualized and physical products. + +As an operator I would like to support onboarding legacy VNFs for my telco +customers where a guest image cannot be modified to work without a HPET. + +Proposed change +=============== + +End users can indicate their desire to have HPET in the guest by specifying a +image property ``hw_time_hpet=True``. + +Setting the new image property to "True" would only be guaranteed to be valid +in combination with ``hypervisor_type=qemu`` and either ``architecture=i686`` +or ``architecture=x86_64``. + +.. note:: A corresponding flavor extra spec will not be introduced since + enabling HPET is really a per-image concern rather than a resource concern + for capacity planning. + +A few options to use Traits were considered as described in the next section, +but we end up choosing the simpler approach due to the following reasons: + +1) HPET is provided by qemu via emulation, so there are no security + implications as there are already better clock sources available. + +2) The HPET was turned off by default purely because of issues with time + drifting on Windows guests. (See nova commit ba3fd16605.) + +3) The emulated HPET device is unconditionally available on all versions of + libvirt/qemu supported by OpenStack. + +4) The HPET device is only supported for x86 architectures, so in a cloud with + a mix of architectures the image would have to be specific to ensure the + instance is scheduled on an x86 host. + +5) Initially we would only support enabling HPET on qemu. Specifying the + hypervisor type will ensure the instance is scheduled on a host using the + qemu hypervisor. It would be possible to extend this to other hypervisors + as well if applicable (vmware supports the ability to enable/disable HPET, + I think), and which ones are supported could be documented in the "useful + image properties" documentation. + + +Alternatives +------------ + +The following options to use Trait were considered, but ultimatedly we chose +a simpler approach without using Trait. + +Explicit Trait, Implicit Config +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Operators can indicate their desire to have HPET in the guest by specifying a +placement trait ``trait:COMPUTE_TIME_HPET=required`` in the flavor extra-specs. + +End users can indicate their desire to have HPET in the guest by uploading +their own images with the same trait. + +Existing nova scheduler code picks up the trait and passes it to +``GET /allocation_candidates``. + +Once scheduled to a compute node, the virt driver looks for +``trait:COMPUTE_TIME_HPET=required`` in the flavor/image or +``trait*:COMPUTE_TIME_HPET=required`` for numbered request group in flavor and +uses that as its cue to enable HPET on the guest. + +If we do get down to the virt driver and the trait is set, and the driver for +whatever reason (e.g. value(s) wrong in the flavor; wind up on a host that +doesn't support HPET etc.) determines it's not capable of flipping the switch, +it should fail. [1]_ + +**CON:** We're using a trait to effect guest configuration. + +Explicit Config, Implicit Trait +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Operator specifies extra spec ``hw:hpet=True`` in the flavor. +* Nova recognizes this as a known special case and adds + ``required=COMPUTE_TIME_HPET`` to the ``GET /allocation_candidates`` query. +* The driver uses the ``hw:hpet=True`` extra spec as its cue to enable HPET on + the guest. + +**CON:** The implicit transformation of a special extra spec into +placement-isms is arcane. This wouldn't be the only instance of this; we would +need to organize the "special" extra specs in the code for maintainability, and +document them thoroughly. + +Explicit Config, Explicit Trait +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Operator specifies **both** extra specs, ``hw:hpet=True`` and + ``trait:COMPUTE_TIME_HPET=required``, in the flavor. +* Existing nova scheduler code picks up the latter and passes it to ``GET + /allocation_candidates``. +* The driver uses the ``hw:hpet=True`` extra spec as its cue to enable HPET on + the guest. + +**CON:** The operator has to remember to set both extra specs, which is kind of +gross UX. (If she forgets ``hw:hpet=True``, she ends up with HPET off; if she +forgets ``trait:COMPUTE_TIME_HPET=required``, she can end up with late-failing +NoValidHosts.) + +Data model impact +----------------- + +None + +REST API impact +--------------- + +None + +Security impact +--------------- + +None + +Notifications impact +-------------------- + +None + +Other end user impact +--------------------- + +None + +Performance Impact +------------------ + +Negligible. + + +Other deployer impact +--------------------- + +None + +Developer impact +---------------- + +None + +Upgrade impact +-------------- + +The new image property will only work reliably after all nodes have been +upgraded. + + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + jackding + +Other contributors: + jaypipes, efried + +Work Items +---------- + +* libvirt driver changes to support HPET + +Dependencies +============ + +None + +Testing +======= + +Will add unit tests. + + +Documentation Impact +==================== + +Update User Documentation for image properties [2]_. + +References +========== + +.. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-October/135446.html +.. [2] https://docs.openstack.org/glance/latest/admin/useful-image-properties.html + +History +======= + +.. list-table:: Revisions + :header-rows: 1 + + * - Release Name + - Description + * - Stein + - Introduced