Evacuate instances

admin

To find a host for the evacuated instance, list all hosts:

3 U: }: m0 F7 s$ openstack host list
9 Y8 c( b/ C8 \, o: mEvacuate the instance. You can use the --password PWD option to pass the instance password to the command. If you do not specify a password, the command generates and prints one after it finishes successfully. The following command evacuates a server from a failed host to HOST_B.

$ nova evacuate EVACUATED_SERVER_NAME HOST_B
The command rebuilds the instance from the original image or volume and returns a password. The command preserves the original configuration, which includes the instance ID, name, uid, IP address, and so on.

3 O( p/ X& S& n+-----------+--------------+
  S, E3 O4 T9 R2 v- o4 ^- w* l' g* h| Property  |    Value     |
, o& K6 a* v* j8 m) J+-----------+--------------+
- j! ?+ V+ u# m* W" r" d" Y. z| adminPass | kRAJpErnT4xZ |
+-----------+--------------+
' I9 D, B* @7 q# tTo preserve the user disk data on the evacuated server, deploy Compute with a shared file system. To configure your system, see Configure live migrations. The following example does not change the password.

% J. f7 C! J2 r% f+ h/ o$ nova evacuate EVACUATED_SERVER_NAME HOST_B --on-shared-storage
+ h5 a8 i' W& H1 \9 Y- k' A& Y

2 v9 O5 j- a2 n. X* GA flavor consists of the following parameters:
6 i6 ~2 h* I1 e0 m) b6 y
Flavor ID
Unique ID (integer or UUID) for the new flavor. If specifying 'auto', a UUID will be automatically generated.
: _# H4 y! t+ U7 M; YName
9 b/ v/ O* X7 I& \Name for the new flavor.
( @- @) n# d' H1 Z+ P3 `VCPUs
Number of virtual CPUs to use.
Memory MB
3 u- [% r, e' l. `Amount of RAM to use (in megabytes).
9 @( Y+ T; p% n8 \  E& ARoot Disk GB
) }7 j0 X& [5 M( m4 ^Amount of disk space (in gigabytes) to use for the root (/) partition. This property is required.
) J) {/ Z  d$ M/ P2 J$ ^# J
: f/ A  |9 Y2 i9 wThe root disk is an ephemeral disk that the base image is copied into. When booting from a persistent volume it is not used. The 0 size is a special case which uses the native base image size as the size of the ephemeral root volume. However, in this case the filter scheduler cannot select the compute host based on the virtual image size. As a result, 0 should only be used for volume booted instances or for testing purposes. Volume-backed instances can be enforced for flavors with zero root disk via the os_compute_api:servers:create:zero_disk_flavor policy rule.
" @& @# L+ t7 h% c2 t
, `/ I" L) [) @) L( {- R* dEphemeral Disk GB
. m1 ]) w! T0 H7 C, q! pAmount of disk space (in gigabytes) to use for the ephemeral partition. If unspecified, the value is 0 by default. Ephemeral disks offer machine local disk storage linked to the lifecycle of a VM instance. When a VM is terminated, all data on the ephemeral disk is lost. Ephemeral disks are not included in any snapshots.
Swap
Amount of swap space (in megabytes) to use. If unspecified, the value is 0 by default.
RXTX Factor
Optional property that allows servers with a different bandwidth be created with the RXTX Factor. The default value is 1.0. That is, the new bandwidth is the same as that of the attached network. The RXTX Factor is available only for Xen or NSX based systems.
Is Public
* H  V( R! R' z7 q; UBoolean value defines whether the flavor is available to all users. Defaults to True.
$ O3 K( ?: r  d" N0 K- oExtra Specs
: w; s2 {3 F0 D/ O) fKey and value pairs that define on which compute nodes a flavor can run. These pairs must match corresponding pairs on the compute nodes. It can be used to implement special resources, such as flavors that run on only compute nodes with GPU hardware.
. ?7 L* w/ A. B/ K4 }7 L$ a. tAs of Newton, there are no default flavors. The following table lists the default flavors for Mitaka and earlier.

" ~' B* o; p. _4 ]Flavor        VCPUs        Disk (in GB)        RAM (in MB)
9 L/ {# Y. O" [m1.tiny        1        1        512
m1.small        1        20        2048
. G) o# \' ^! |7 d% x% {9 ^  {m1.medium        2        40        4096
m1.large        4        80        8192
  }5 R' `. x* Mm1.xlarge        8        160        16384
You can create and manage flavors with the openstack flavor commands provided by the python-openstackclient package.
# k; x  T7 l! {. h3 d: V
Create a flavor¶
5 L# d6 S) t6 C* E* b! bList flavors to show the ID and name, the amount of memory, the amount of disk space for the root partition and for the ephemeral partition, the swap, and the number of virtual CPUs for each flavor:

$ openstack flavor list
; D) o: H: t1 X$ yTo create a flavor, specify a name, ID, RAM size, disk size, and the number of VCPUs for the flavor, as follows:
4 d2 R& X$ N& b  D; T0 ^! B4 W7 Q
$ openstack flavor create FLAVOR_NAME --id FLAVOR_ID \
    --ram RAM_IN_MB --disk ROOT_DISK_IN_GB --vcpus NUMBER_OF_VCPUS
Note
; T5 P7 t8 D" I  Y1 b, u- w$ j7 I
Unique ID (integer or UUID) for the new flavor. If specifying 'auto', a UUID will be automatically generated.
2 |& z9 W9 x' i; a2 h% N! L+ ]8 T/ CHere is an example with additional optional parameters filled in that creates a public extra_tiny flavor that automatically gets an ID assigned, with 256 MB memory, no disk space, and one VCPU. The rxtx-factor indicates the slice of bandwidth that the instances with this flavor can use (through the Virtual Interface (vif) creation in the hypervisor):
; g8 C+ B4 p5 u. u
9 ]1 s1 J. H5 K' r$ openstack flavor create --public m1.extra_tiny --id auto \
4 j" @( F0 d* \% l% y1 d    --ram 256 --disk 0 --vcpus 1 --rxtx-factor 1
If an individual user or group of users needs a custom flavor that you do not want other projects to have access to, you can change the flavor's access to make it a private flavor. See Private Flavors in the OpenStack Operations Guide.

For a list of optional parameters, run this command:

+ K. Q1 F2 ]3 [9 @. w$ openstack help flavor create
After you create a flavor, assign it to a project by specifying the flavor name or ID and the project ID:

$ nova flavor-access-add FLAVOR TENANT_ID
In addition, you can set or unset extra_spec for the existing flavor. The extra_spec metadata keys can influence the instance directly when it is launched. If a flavor sets the extra_spec key/value quota:vif_outbound_peak=65536, the instance's outbound peak bandwidth I/O should be less than or equal to 512 Mbps. There are several aspects that can work for an instance including CPU limits, Disk tuning, Bandwidth I/O, Watchdog behavior, and Random-number generator. For information about supporting metadata keys, see Flavors.
6 q8 O* o; `7 S4 \& X, [
For a list of optional parameters, run this command:

- J" e: c; Y1 L7 T3 p% D$ nova help flavor-key
1 o* _/ L3 _% b5 E3 D; a" ~Delete a flavor¶
' i% j. Z- ]5 _; x3 z. a% ADelete a specified flavor, as follows:
1 L, P/ X9 g. _( W, d& v1 P
0 z; o; m/ m* @6 J$ openstack flavor delete FLAVOR_ID
5 e5 c5 L$ D6 d

Admin users can use the openstack flavor command to customize and manage flavors. To see information for this command, run:

6 x1 p5 w6 L/ o/ R# Z0 p- d$ openstack flavor --help
Command "flavor" matches:
  flavor create
* u* l$ @. h) X6 i9 z4 d  flavor delete
  flavor list
  flavor set
9 U! P7 J; r1 X2 k- @1 o  flavor show
6 I& O% W+ M- V) [4 s  i1 c: j  flavor unset
# o8 J$ y- O* T$ g* Z( n- M- Q Note

. p% C) L2 a1 _2 e% |+ TConfiguration rights can be delegated to additional users by redefining the access controls for os_compute_api:os-flavor-manage in /etc/nova/policy.json on the nova-api server.
9 w5 j3 G3 y5 ?Flavors define these elements:

2 w7 x, [- z2 ]: mTodo
) ?: ^$ C: p" X1 w+ M* ~7 y  l
This would be much easier to read as a list-table or similar
: i' g" Y* r. g2 q% nElement        Description
Name        A descriptive name. XX.SIZE_NAME is typically not required, though some third party tools may rely on it.
Memory MB        Instance memory in megabytes.
+ k2 _* S: K% R7 nDisk        Virtual root disk size in gigabytes. This is an ephemeral disk that the base image is copied into. When booting from a persistent volume it is not used. The "0" size is a special case which uses the native base image size as the size of the ephemeral root volume. However, in this case the filter scheduler cannot select the compute host based on the virtual image size. Therefore 0 should only be used for volume booted instances or for testing purposes.
Ephemeral        Specifies the size of a secondary ephemeral data disk. This is an empty, unformatted disk and exists only for the life of the instance. Default value is 0.
# b2 Q+ k( Y1 x0 ^6 pSwap        Optional swap space allocation for the instance. Default value is 0.
+ c1 s2 A, \5 oVCPUs        Number of virtual CPUs presented to the instance.
1 y9 ~2 b$ q) H' x2 @! Q2 {) z9 YRXTX Factor        Optional property allows created servers to have a different bandwidth cap than that defined in the network they are attached to. This factor is multiplied by the rxtx_base property of the network. Default value is 1.0. That is, the same as attached network. This parameter is only available for Xen or NSX based systems.
4 J* o1 [! p5 v1 j, B! g; zIs Public        Boolean value, whether flavor is available to all users or private to the project it was created in. Defaults to True.
2 ~3 Z! |+ ?+ G: V7 A, fExtra Specs        Key and value pairs that define on which compute nodes a flavor can run. These pairs must match corresponding pairs on the compute nodes. Use to implement special resources, such as flavors that run on only compute nodes with GPU hardware.
5 ~7 v  F0 s/ H$ Z: M Note
1 ]" s# R  }* G* ^" D/ x; t+ n
Flavor customization can be limited by the hypervisor in use. For example the libvirt driver enables quotas on CPUs available to a VM, disk tuning, bandwidth I/O, watchdog behavior, random number generator device control, and instance VIF traffic control.
Is Public¶
Flavors can be assigned to particular projects. By default, a flavor is public and available to all projects. Private flavors are only accessible to those on the access list and are invisible to other projects. To create and assign a private flavor to a project, run this command:

3 A( [. w6 Q% V  b2 `$ openstack flavor create --private p1.medium --id auto --ram 512 --disk 40 --vcpus 4
8 ~+ l8 ?6 |4 ~1 t! s0 f; }+ P9 i7 vExtra Specs¶
CPU limits
You can configure the CPU limits with control parameters with the nova client. For example, to configure the I/O limit, use:

# i- v5 X' M. t% c6 o8 o$ openstack flavor set FLAVOR-NAME \
    --property quota:read_bytes_sec=10240000 \
6 a" Q: {+ [8 h& ~1 ?# f    --property quota:write_bytes_sec=10240000
Use these optional parameters to control weight shares, enforcement intervals for runtime quotas, and a quota for maximum allowed bandwidth:

cpu_shares: Specifies the proportional weighted share for the domain. If this element is omitted, the service defaults to the OS provided defaults. There is no unit for the value; it is a relative measure based on the setting of other VMs. For example, a VM configured with value 2048 gets twice as much CPU time as a VM configured with value 1024.
- R; X0 L1 i9 I% {5 Q1 X5 K
) U+ N" s" n" Q& s* Tcpu_shares_level: On VMware, specifies the allocation level. Can be custom, high, normal, or low. If you choose custom, set the number of shares using cpu_shares_share.
4 C  o; o2 j& s" T. z! U% X6 v
0 M# }: D( ^, E, X9 W& U5 fcpu_period: Specifies the enforcement interval (unit: microseconds) for QEMU and LXC hypervisors. Within a period, each VCPU of the domain is not allowed to consume more than the quota worth of runtime. The value should be in range [1000, 1000000]. A period with value 0 means no value.

2 \2 |5 ]( Z. e/ M: Wcpu_limit: Specifies the upper limit for VMware machine CPU allocation in MHz. This parameter ensures that a machine never uses more than the defined amount of CPU time. It can be used to enforce a limit on the machine's CPU performance.

cpu_reservation: Specifies the guaranteed minimum CPU reservation in MHz for VMware. This means that if needed, the machine will definitely get allocated the reserved amount of CPU cycles.
, v' K: q, Z( L& L
) m- f3 u$ J- {1 r8 K1 Dcpu_quota: Specifies the maximum allowed bandwidth (unit: microseconds). A domain with a negative-value quota indicates that the domain has infinite bandwidth, which means that it is not bandwidth controlled. The value should be in range [1000, 18446744073709551] or less than 0. A quota with value 0 means no value. You can use this feature to ensure that all vCPUs run at the same speed. For example:

$ openstack flavor set FLAVOR-NAME \
    --property quota:cpu_quota=10000 \
    --property quota:cpu_period=20000
In this example, an instance of FLAVOR-NAME can only consume a maximum of 50% CPU of a physical CPU computing capability.

/ B: ~; n$ o- S6 T3 gMemory limits
For VMware, you can configure the memory limits with control parameters.
' B/ O) C# D6 ]+ N
Use these optional parameters to limit the memory allocation, guarantee minimum memory reservation, and to specify shares used in case of resource contention:
# K( x; R! E: r* F
6 h6 T% K4 E" r: k# b  Smemory_limit: Specifies the upper limit for VMware machine memory allocation in MB. The utilization of a virtual machine will not exceed this limit, even if there are available resources. This is typically used to ensure a consistent performance of virtual machines independent of available resources.

" z% N. M! v. @- amemory_reservation: Specifies the guaranteed minimum memory reservation in MB for VMware. This means the specified amount of memory will definitely be allocated to the machine.
1 i, e/ V$ [1 _7 W, I+ Y( f
$ f' d( ]" c' _memory_shares_level: On VMware, specifies the allocation level. This can be custom, high, normal or low. If you choose custom, set the number of shares using memory_shares_share.

5 l2 a% @# Z2 l7 ~$ Fmemory_shares_share: Specifies the number of shares allocated in the event that custom is used. There is no unit for this value. It is a relative measure based on the settings for other VMs. For example:

6 i+ f' `0 x1 V5 k$ openstack flavor set FLAVOR-NAME \
    --property quota:memory_shares_level=custom \
    --property quota:memory_shares_share=15
Disk I/O limits
For VMware, you can configure the resource limits for disk with control parameters.
+ l% E9 T$ q* n/ P- M9 j5 v
# Z4 e* _% @- F  T+ n8 rUse these optional parameters to limit the disk utilization, guarantee disk allocation, and to specify shares used in case of resource contention. This allows the VMware driver to enable disk allocations for the running instance.

; c# z0 j5 \2 O* u. c0 O9 fdisk_io_limit: Specifies the upper limit for disk utilization in I/O per second. The utilization of a virtual machine will not exceed this limit, even if there are available resources. The default value is -1 which indicates unlimited usage.

$ j3 d4 M& l; L! O& t0 Adisk_io_reservation: Specifies the guaranteed minimum disk allocation in terms of Input/output Operations Per Second (IOPS).
' h& ~  [* `" n# y( @; `
, A# C  W- B. {6 A: Mdisk_io_shares_level: Specifies the allocation level. This can be custom, high, normal or low. If you choose custom, set the number of shares using disk_io_shares_share.
% L0 Z7 T- {' Q2 O$ g
disk_io_shares_share: Specifies the number of shares allocated in the event that custom is used. When there is resource contention, this value is used to determine the resource allocation.
) e. {; s% t+ S. N" n. g; m2 A
The example below sets the disk_io_reservation to 2000 IOPS.

$ openstack flavor set FLAVOR-NAME \
    --property quota:disk_io_reservation=2000
( O; Q* ]# N: ?! P6 MDisk tuning
; d" E; S) d* S+ P+ }Using disk I/O quotas, you can set maximum disk write to 10 MB per second for a VM user. For example:
0 w3 e- G. u: j1 ]. L) g* ~! o9 T
/ D. W! E; v6 H$ openstack flavor set FLAVOR-NAME \
4 h) w8 w7 h2 V# W7 ?    --property quota:disk_write_bytes_sec=10485760
The disk I/O options are:

. Z) ?2 R1 @9 h' P9 ]disk_read_bytes_sec
$ ?$ ]! J: y" l$ f# u( c, q0 bdisk_read_iops_sec
  C9 i$ }( j2 |# I; z) {9 cdisk_write_bytes_sec
: m$ \0 j/ M; y$ h- U% Udisk_write_iops_sec
disk_total_bytes_sec
* H" H+ U  J0 K; }' C3 p, P2 E$ Q) gdisk_total_iops_sec
5 B1 u8 ^! O5 v7 I& g7 k  d( cBandwidth I/O
" P5 v% S0 S/ ^. M1 IThe vif I/O options are:

" P7 a% A; r( p* qvif_inbound_average
# i/ k: B. u& O6 {( p# `vif_inbound_burst
0 Q/ N4 o& A* B* \4 g. pvif_inbound_peak
vif_outbound_average
9 o& ]# M9 B/ B! E, T! {+ X( Mvif_outbound_burst
" w7 |  E/ v8 w& @5 svif_outbound_peak
Incoming and outgoing traffic can be shaped independently. The bandwidth element can have at most, one inbound and at most, one outbound child element. If you leave any of these child elements out, no quality of service (QoS) is applied on that traffic direction. So, if you want to shape only the network's incoming traffic, use inbound only (and vice versa). Each element has one mandatory attribute average, which specifies the average bit rate on the interface being shaped.

There are also two optional attributes (integer): peak, which specifies the maximum rate at which a bridge can send data (kilobytes/second), and burst, the amount of bytes that can be burst at peak speed (kilobytes). The rate is shared equally within domains connected to the network.
4 _0 T8 C7 W. p8 W6 I4 r, e
7 d5 O0 Y  Z& z: A+ c$ @The example below sets network traffic bandwidth limits for existing flavor as follows:
, k' ^6 b  Q# X' N2 N' R
Outbound traffic:
! x; S8 E: I+ ~) n2 p. v  Haverage: 262 Mbps (32768 kilobytes/second)
* u4 m" _) j: {; b4 E5 P' E) gpeak: 524 Mbps (65536 kilobytes/second)
, R( q& z8 A% X% wburst: 65536 kilobytes
9 L$ X; @* M2 ]Inbound traffic:
1 w# }2 Y% X% z- @  maverage: 262 Mbps (32768 kilobytes/second)
peak: 524 Mbps (65536 kilobytes/second)
burst: 65536 kilobytes
$ openstack flavor set FLAVOR-NAME \
    --property quota:vif_outbound_average=32768 \
& t! [, ]7 `9 D& x) j    --property quota:vif_outbound_peak=65536 \
% H: T2 f: Z. f+ I- X' z4 k    --property quota:vif_outbound_burst=65536 \
9 t' K: }- c' I8 J  B! F5 q; r+ s    --property quota:vif_inbound_average=32768 \
' ]$ W$ q; r6 V4 y3 R    --property quota:vif_inbound_peak=65536 \
    --property quota:vif_inbound_burst=65536
% K6 v" Y. _+ ?0 i, ^ Note
, i+ m0 W! G- P+ N+ m, U0 X
/ ^& U/ L" @- i& KAll the speed limit values in above example are specified in kilobytes/second. And burst values are in kilobytes. Values were converted using 'Data rate units on Wikipedia <https://en.wikipedia.org/wiki/Data_rate_units>`_.
Watchdog behavior
+ ^) ]* F7 x' `9 ~8 Y. `8 @  fFor the libvirt driver, you can enable and set the behavior of a virtual hardware watchdog device for each flavor. Watchdog devices keep an eye on the guest server, and carry out the configured action, if the server hangs. The watchdog uses the i6300esb device (emulating a PCI Intel 6300ESB). If hw:watchdog_action is not specified, the watchdog is disabled.
, o5 {: A0 R1 R
5 z4 S+ ]! C- v& B) sTo set the behavior, use:

$ openstack flavor set FLAVOR-NAME --property hw:watchdog_action=ACTION
! X' r  w# \+ D8 hValid ACTION values are:

$ |! u8 J% O2 f+ ]$ r1 h: i+ K0 [disabled: (default) The device is not attached.
reset: Forcefully reset the guest.
poweroff: Forcefully power off the guest.
pause: Pause the guest.
! F2 Z$ Y( s: ]  h$ Z5 Onone: Only enable the watchdog; do nothing if the server hangs.
( T2 A5 ?+ }5 Q& g2 G Note

, Z6 R6 C) a1 x  s# G3 m6 UWatchdog behavior set using a specific image's properties will override behavior set using flavors.
Random-number generator
If a random-number generator device has been added to the instance through its image properties, the device can be enabled and configured using:

$ openstack flavor set FLAVOR-NAME \
# z6 h, I' x# T& X2 E3 E    --property hw_rng:allowed=True \
    --property hw_rng:rate_bytes=RATE-BYTES \
/ j, ~$ [9 I' T5 l    --property hw_rng:rate_period=RATE-PERIOD
9 B! ^# U. z8 _' vWhere:

) D5 h( v9 Z  r9 t( X8 ?1 dRATE-BYTES: (integer) Allowed amount of bytes that the guest can read from the host's entropy per period.
- r: n& Q- ~8 f/ m. JRATE-PERIOD: (integer) Duration of the read period in seconds.
CPU topology
For the libvirt driver, you can define the topology of the processors in the virtual machine using properties. The properties with max limit the number that can be selected by the user with image properties.
0 d0 J9 f/ v; u  M/ e
4 a' B% c; _5 j& h5 C: O$ openstack flavor set FLAVOR-NAME \
    --property hw:cpu_sockets=FLAVOR-SOCKETS \
7 {8 V2 E1 X  ~+ t: `    --property hw:cpu_cores=FLAVOR-CORES \
    --property hw:cpu_threads=FLAVOR-THREADS \
8 R; C( J/ w7 O; o    --property hw:cpu_max_sockets=FLAVOR-SOCKETS \
5 f1 R, q. k8 q6 X- Q    --property hw:cpu_max_cores=FLAVOR-CORES \
$ ?, H; j' c2 [5 r" u+ X  @    --property hw:cpu_max_threads=FLAVOR-THREADS
Where:

' f& e. A0 u# L8 n0 ~( NFLAVOR-SOCKETS: (integer) The number of sockets for the guest VM. By default, this is set to the number of vCPUs requested.
FLAVOR-CORES: (integer) The number of cores per socket for the guest VM. By default, this is set to 1.
FLAVOR-THREADS: (integer) The number of threads per core for the guest VM. By default, this is set to 1.
8 M/ k; O& p& q/ d6 W7 m. cCPU pinning policy
: E3 A" q# J; C+ c+ \" i4 [For the libvirt driver, you can pin the virtual CPUs (vCPUs) of instances to the host's physical CPU cores (pCPUs) using properties. You can further refine this by stating how hardware CPU threads in a simultaneous multithreading-based (SMT) architecture be used. These configurations will result in improved per-instance determinism and performance.

Note

SMT-based architectures include Intel processors with Hyper-Threading technology. In these architectures, processor cores share a number of components with one or more other cores. Cores in such architectures are commonly referred to as hardware threads, while the cores that a given core share components with are known as thread siblings.
Note
  d- [$ y3 Y3 b% z/ U. h. k& ^
Host aggregates should be used to separate these pinned instances from unpinned instances as the latter will not respect the resourcing requirements of the former.
7 y5 R9 {( T' m3 K3 e  y2 u  Z4 b$ openstack flavor set FLAVOR-NAME \
    --property hw:cpu_policy=CPU-POLICY \
    --property hw:cpu_thread_policy=CPU-THREAD-POLICY
Valid CPU-POLICY values are:
  \/ H  w9 Q6 K
  K0 l4 `( c4 ^: q8 vshared: (default) The guest vCPUs will be allowed to freely float across host pCPUs, albeit potentially constrained by NUMA policy.
dedicated: The guest vCPUs will be strictly pinned to a set of host pCPUs. In the absence of an explicit vCPU topology request, the drivers typically expose all vCPUs as sockets with one core and one thread. When strict CPU pinning is in effect the guest CPU topology will be setup to match the topology of the CPUs to which it is pinned. This option implies an overcommit ratio of 1.0. For example, if a two vCPU guest is pinned to a single host core with two threads, then the guest will get a topology of one socket, one core, two threads.
$ u. k  Q# y& o! f9 J& I- [Valid CPU-THREAD-POLICY values are:

prefer: (default) The host may or may not have an SMT architecture. Where an SMT architecture is present, thread siblings are preferred.
isolate: The host must not have an SMT architecture or must emulate a non-SMT architecture. If the host does not have an SMT architecture, each vCPU is placed on a different core as expected. If the host does have an SMT architecture - that is, one or more cores have thread siblings - then each vCPU is placed on a different physical core. No vCPUs from other guests are placed on the same core. All but one thread sibling on each utilized core is therefore guaranteed to be unusable.
5 f/ A3 W. d; u+ ~8 p* V5 Prequire: The host must have an SMT architecture. Each vCPU is allocated on thread siblings. If the host does not have an SMT architecture, then it is not used. If the host has an SMT architecture, but not enough cores with free thread siblings are available, then scheduling fails.
Note

* n# l8 z) R+ s0 `The hw:cpu_thread_policy option is only valid if hw:cpu_policy is set to dedicated.
NUMA topology
For the libvirt driver, you can define the host NUMA placement for the instance vCPU threads as well as the allocation of instance vCPUs and memory from the host NUMA nodes. For flavors whose memory and vCPU allocations are larger than the size of NUMA nodes in the compute hosts, the definition of a NUMA topology allows hosts to better utilize NUMA and improve performance of the instance OS.

$ openstack flavor set FLAVOR-NAME \
    --property hw:numa_nodes=FLAVOR-NODES \
7 y) m- s1 x- o# n    --property hw:numa_cpus.N=FLAVOR-CORES \
    --property hw:numa_mem.N=FLAVOR-MEMORY
3 @* Y; ]" w4 QWhere:
: K/ I+ V% a) O/ M, b  H
FLAVOR-NODES: (integer) The number of host NUMA nodes to restrict execution of instance vCPU threads to. If not specified, the vCPU threads can run on any number of the host NUMA nodes available.
. U7 s2 X, A$ PN: (integer) The instance NUMA node to apply a given CPU or memory configuration to, where N is in the range 0 to FLAVOR-NODES - 1.
! X( {, v5 D6 g9 E9 r4 hFLAVOR-CORES: (comma-separated list of integers) A list of instance vCPUs to map to instance NUMA node N. If not specified, vCPUs are evenly divided among available NUMA nodes.
FLAVOR-MEMORY: (integer) The number of MB of instance memory to map to instance NUMA node N. If not specified, memory is evenly divided among available NUMA nodes.
' P2 k" F2 z& f8 k8 ?5 O Note

hw:numa_cpus.N and hw:numa_mem.N are only valid if hw:numa_nodes is set. Additionally, they are only required if the instance's NUMA nodes have an asymmetrical allocation of CPUs and RAM (important for some NFV workloads).
: V) h4 i- `  F3 j1 b* @& c Note

The N parameter is an index of guest NUMA nodes and may not correspond to host NUMA nodes. For example, on a platform with two NUMA nodes, the scheduler may opt to place guest NUMA node 0, as referenced in hw:numa_mem.0 on host NUMA node 1 and vice versa. Similarly, the integers used for FLAVOR-CORES are indexes of guest vCPUs and may not correspond to host CPUs. As such, this feature cannot be used to constrain instances to specific host CPUs or NUMA nodes.
$ `- x# D/ _( _  |& }0 B Warning
- p; h' \/ J; {, @" }
! D. Z; K+ c+ @# U* J: r$ k" jIf the combined values of hw:numa_cpus.N or hw:numa_mem.N are greater than the available number of CPUs or memory respectively, an exception is raised.
Large pages allocation
You can configure the size of large pages used to back the VMs.

. w$ @4 Y7 ^. ~! Y- s) ?$ openstack flavor set FLAVOR-NAME \
% z- v4 i/ H+ V# E6 m5 C    --property hw:mem_page_size=PAGE_SIZE
" ]) K$ H- ~9 ~, L0 o/ @Valid PAGE_SIZE values are:
' W1 n/ |5 O" c6 P5 s" U
small: (default) The smallest page size is used. Example: 4 KB on x86.
& V6 w) j, Q5 a9 ?( hlarge: Only use larger page sizes for guest RAM. Example: either 2 MB or 1 GB on x86.
* X* r* u1 f2 S0 f! L9 P+ hany: It is left up to the compute driver to decide. In this case, the libvirt driver might try to find large pages, but fall back to small pages. Other drivers may choose alternate policies for any.
pagesize: (string) An explicit page size can be set if the workload has specific requirements. This value can be an integer value for the page size in KB, or can use any standard suffix. Example: 4KB, 2MB, 2048, 1GB.
4 G1 |4 j! r7 M( F Note

Large pages can be enabled for guest RAM without any regard to whether the guest OS will use them or not. If the guest OS chooses not to use huge pages, it will merely see small pages as before. Conversely, if a guest OS does intend to use huge pages, it is very important that the guest RAM be backed by huge pages. Otherwise, the guest OS will not be getting the performance benefit it is expecting.
PCI passthrough
4 n7 }  `& o( ~. m! aYou can assign PCI devices to a guest by specifying them in the flavor.

$ openstack flavor set FLAVOR-NAME \
: q6 f" Q3 }0 E    --property pci_passthrough:alias=ALIAS:COUNT
' n; Q6 l" E" B1 iWhere:

9 N6 H9 f/ u! ^& nALIAS: (string) The alias which correspond to a particular PCI device class as configured in the nova configuration file (see Configuration Options).
COUNT: (integer) The amount of PCI devices of type ALIAS to be assigned to a guest.
7 b9 E1 H- G0 K8 [Secure Boot
' L! Z$ l. {& }7 u# b2 VWhen your Compute services use the Hyper-V hypervisor, you can enable secure boot for Windows and Linux instances.
7 H+ x7 n3 Y" p9 K: M0 Y
' K# Q( P+ V( R% {7 |. }, V7 E$ openstack flavor set FLAVOR-NAME \
+ y/ ~  b: ~+ _8 F" i. ?) y    --property os:secure_boot=SECURE_BOOT_OPTION
Valid SECURE_BOOT_OPTION values are:

8 Z9 z( ~6 i" D4 d( brequired: Enable Secure Boot for instances running with this flavor.
disabled or optional: (default) Disable Secure Boot for instances running with this flavor.
4 w& x) h1 A& N