![melanie witt](/assets/img/avatar_default.png)
This moves the completed Stein specs to the implemented directory and adds the redirects. This was done using: $ tox -e move-implemented-specs stein This also removes the stein-template symlink from the docs. And renames the handling-down-cell_new.rst spec to handling-down-cell.rst to match the blueprint. Change-Id: Id92bec8c5a2436a4053765f735d252c7c165f019
5.9 KiB
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:
- HPET is provided by qemu via emulation, so there are no security implications as there are already better clock sources available.
- The HPET was turned off by default purely because of issues with time drifting on Windows guests. (See nova commit ba3fd16605.)
- The emulated HPET device is unconditionally available on all versions of libvirt/qemu supported by OpenStack.
- 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.
- 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 theGET /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
andtrait: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 properties2.
References
History
Release Name | Description |
---|---|
Stein | Introduced |