-
Notifications
You must be signed in to change notification settings - Fork 2.5k
/
libvirt.py
1568 lines (1288 loc) · 56.1 KB
/
libvirt.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
# needs:fix_opt_description
# needs:check_deprecation_status
# needs:check_opt_group_and_type
# needs:fix_opt_description_indentation
# needs:fix_opt_registration_consistency
# Copyright 2016 OpenStack Foundation
# All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
import itertools
from oslo_config import cfg
from oslo_config import types
from nova.conf import paths
libvirt_group = cfg.OptGroup("libvirt",
title="Libvirt Options",
help="""
Libvirt options allows cloud administrator to configure related
libvirt hypervisor driver to be used within an OpenStack deployment.
Almost all of the libvirt config options are influence by ``virt_type`` config
which describes the virtualization type (or so called domain type) libvirt
should use for specific features such as live migration, snapshot.
""")
libvirt_general_opts = [
cfg.StrOpt('rescue_image_id',
help="""
The ID of the image to boot from to rescue data from a corrupted instance.
If the rescue REST API operation doesn't provide an ID of an image to
use, the image which is referenced by this ID is used. If this
option is not set, the image from the instance is used.
Possible values:
* An ID of an image or nothing. If it points to an *Amazon Machine
Image* (AMI), consider to set the config options ``rescue_kernel_id``
and ``rescue_ramdisk_id`` too. If nothing is set, the image of the instance
is used.
Related options:
* ``rescue_kernel_id``: If the chosen rescue image allows the separate
definition of its kernel disk, the value of this option is used,
if specified. This is the case when *Amazon*'s AMI/AKI/ARI image
format is used for the rescue image.
* ``rescue_ramdisk_id``: If the chosen rescue image allows the separate
definition of its RAM disk, the value of this option is used if,
specified. This is the case when *Amazon*'s AMI/AKI/ARI image
format is used for the rescue image.
"""),
cfg.StrOpt('rescue_kernel_id',
help="""
The ID of the kernel (AKI) image to use with the rescue image.
If the chosen rescue image allows the separate definition of its kernel
disk, the value of this option is used, if specified. This is the case
when *Amazon*'s AMI/AKI/ARI image format is used for the rescue image.
Possible values:
* An ID of an kernel image or nothing. If nothing is specified, the kernel
disk from the instance is used if it was launched with one.
Related options:
* ``rescue_image_id``: If that option points to an image in *Amazon*'s
AMI/AKI/ARI image format, it's useful to use ``rescue_kernel_id`` too.
"""),
cfg.StrOpt('rescue_ramdisk_id',
help="""
The ID of the RAM disk (ARI) image to use with the rescue image.
If the chosen rescue image allows the separate definition of its RAM
disk, the value of this option is used, if specified. This is the case
when *Amazon*'s AMI/AKI/ARI image format is used for the rescue image.
Possible values:
* An ID of a RAM disk image or nothing. If nothing is specified, the RAM
disk from the instance is used if it was launched with one.
Related options:
* ``rescue_image_id``: If that option points to an image in *Amazon*'s
AMI/AKI/ARI image format, it's useful to use ``rescue_ramdisk_id`` too.
"""),
cfg.StrOpt('virt_type',
default='kvm',
choices=('kvm', 'lxc', 'qemu', 'parallels'),
help="""
Describes the virtualization type (or so called domain type) libvirt should
use.
The choice of this type must match the underlying virtualization strategy
you have chosen for this host.
Related options:
* ``connection_uri``: depends on this
* ``disk_prefix``: depends on this
* ``cpu_mode``: depends on this
* ``cpu_models``: depends on this
* ``tb_cache_size``: depends on this
"""),
cfg.StrOpt('connection_uri',
default='',
help="""
Overrides the default libvirt URI of the chosen virtualization type.
If set, Nova will use this URI to connect to libvirt.
Possible values:
* An URI like ``qemu:///system``.
This is only necessary if the URI differs to the commonly known URIs
for the chosen virtualization type.
Related options:
* ``virt_type``: Influences what is used as default value here.
"""),
cfg.BoolOpt('inject_password',
default=False,
help="""
Allow the injection of an admin password for instance only at ``create`` and
``rebuild`` process.
There is no agent needed within the image to do this. If *libguestfs* is
available on the host, it will be used. Otherwise *nbd* is used. The file
system of the image will be mounted and the admin password, which is provided
in the REST API call will be injected as password for the root user. If no
root user is available, the instance won't be launched and an error is thrown.
Be aware that the injection is *not* possible when the instance gets launched
from a volume.
*Linux* distribution guest only.
Possible values:
* True: Allows the injection.
* False: Disallows the injection. Any via the REST API provided admin password
will be silently ignored.
Related options:
* ``inject_partition``: That option will decide about the discovery and usage
of the file system. It also can disable the injection at all.
"""),
cfg.BoolOpt('inject_key',
default=False,
help="""
Allow the injection of an SSH key at boot time.
There is no agent needed within the image to do this. If *libguestfs* is
available on the host, it will be used. Otherwise *nbd* is used. The file
system of the image will be mounted and the SSH key, which is provided
in the REST API call will be injected as SSH key for the root user and
appended to the ``authorized_keys`` of that user. The SELinux context will
be set if necessary. Be aware that the injection is *not* possible when the
instance gets launched from a volume.
This config option will enable directly modifying the instance disk and does
not affect what cloud-init may do using data from config_drive option or the
metadata service.
*Linux* distribution guest only.
Related options:
* ``inject_partition``: That option will decide about the discovery and usage
of the file system. It also can disable the injection at all.
"""),
cfg.IntOpt('inject_partition',
default=-2,
min=-2,
help="""
Determines how the file system is chosen to inject data into it.
*libguestfs* is used to inject data. If libguestfs is not able to determine
the root partition (because there are more or less than one root partition) or
cannot mount the file system it will result in an error and the instance won't
boot.
Possible values:
* -2 => disable the injection of data.
* -1 => find the root partition with the file system to mount with libguestfs
* 0 => The image is not partitioned
* >0 => The number of the partition to use for the injection
*Linux* distribution guest only.
Related options:
* ``inject_key``: If this option allows the injection of a SSH key it depends
on value greater or equal to -1 for ``inject_partition``.
* ``inject_password``: If this option allows the injection of an admin password
it depends on value greater or equal to -1 for ``inject_partition``.
* ``[guestfs]/debug`` You can enable the debug log level of libguestfs with
this config option. A more verbose output will help in debugging issues.
* ``virt_type``: If you use ``lxc`` as virt_type it will be treated as a
single partition image
"""),
cfg.StrOpt('live_migration_scheme',
help="""
URI scheme for live migration used by the source of live migration traffic.
Override the default libvirt live migration scheme (which is dependent on
virt_type). If this option is set to None, nova will automatically choose a
sensible default based on the hypervisor. It is not recommended that you change
this unless you are very sure that hypervisor supports a particular scheme.
Related options:
* ``virt_type``: This option is meaningful only when ``virt_type`` is set to
`kvm` or `qemu`.
* ``live_migration_uri``: If ``live_migration_uri`` value is not None, the
scheme used for live migration is taken from ``live_migration_uri`` instead.
"""),
cfg.HostDomainOpt('live_migration_inbound_addr',
help="""
IP address used as the live migration address for this host.
This option indicates the IP address which should be used as the target for
live migration traffic when migrating to this hypervisor. This metadata is then
used by the source of the live migration traffic to construct a migration URI.
If this option is set to None, the hostname of the migration target compute
node will be used.
This option is useful in environments where the live-migration traffic can
impact the network plane significantly. A separate network for live-migration
traffic can then use this config option and avoids the impact on the
management network.
"""),
cfg.StrOpt('live_migration_uri',
deprecated_for_removal=True,
deprecated_since="15.0.0",
deprecated_reason="""
live_migration_uri is deprecated for removal in favor of two other options that
allow to change live migration scheme and target URI: ``live_migration_scheme``
and ``live_migration_inbound_addr`` respectively.
""",
help="""
Live migration target URI used by the source of live migration traffic.
Override the default libvirt live migration target URI (which is dependent
on virt_type). Any included "%s" is replaced with the migration target
hostname, or `live_migration_inbound_addr` if set.
If this option is set to None (which is the default), Nova will automatically
generate the `live_migration_uri` value based on only 4 supported `virt_type`
in following list:
* 'kvm': 'qemu+tcp://%s/system'
* 'qemu': 'qemu+tcp://%s/system'
* 'parallels': 'parallels+tcp://%s/system'
Related options:
* ``live_migration_inbound_addr``: If ``live_migration_inbound_addr`` value
is not None and ``live_migration_tunnelled`` is False, the ip/hostname
address of target compute node is used instead of ``live_migration_uri`` as
the uri for live migration.
* ``live_migration_scheme``: If ``live_migration_uri`` is not set, the scheme
used for live migration is taken from ``live_migration_scheme`` instead.
"""),
cfg.BoolOpt('live_migration_tunnelled',
default=False,
deprecated_for_removal=True,
deprecated_since='23.0.0',
deprecated_reason="""
The "tunnelled live migration" has two inherent limitations: it cannot
handle live migration of disks in a non-shared storage setup; and it has
a huge performance cost. Both these problems are solved by
``live_migration_with_native_tls`` (requires a pre-configured TLS
environment), which is the recommended approach for securing all live
migration streams.""",
help="""
Enable tunnelled migration.
This option enables the tunnelled migration feature, where migration data is
transported over the libvirtd connection. If enabled, we use the
VIR_MIGRATE_TUNNELLED migration flag, avoiding the need to configure
the network to allow direct hypervisor to hypervisor communication.
If False, use the native transport. If not set, Nova will choose a
sensible default based on, for example the availability of native
encryption support in the hypervisor. Enabling this option will definitely
impact performance massively.
Note that this option is NOT compatible with use of block migration.
"""),
cfg.IntOpt('live_migration_bandwidth',
default=0,
help="""
Maximum bandwidth(in MiB/s) to be used during migration.
If set to 0, the hypervisor will choose a suitable default. Some hypervisors
do not support this feature and will return an error if bandwidth is not 0.
Please refer to the libvirt documentation for further details.
"""),
cfg.IntOpt('live_migration_downtime',
default=500,
min=100,
help="""
Target maximum period of time Nova will try to keep the instance paused
during the last part of the memory copy, in *milliseconds*.
Minimum downtime is 100ms. You can increase this value if you want to allow
live-migrations to complete faster, or avoid live-migration timeout errors
by allowing the guest to be paused for longer during the live-migration switch
over. This value may be exceeded if there is any reduction on the transfer rate
after the VM is paused.
Related options:
* live_migration_completion_timeout
"""),
cfg.IntOpt('live_migration_downtime_steps',
default=10,
min=3,
help="""
Number of incremental steps to reach max downtime value.
Minimum number of steps is 3.
"""),
cfg.IntOpt('live_migration_downtime_delay',
default=75,
min=3,
help="""
Time to wait, in seconds, between each step increase of the migration
downtime.
Minimum delay is 3 seconds. Value is per GiB of guest RAM + disk to be
transferred, with lower bound of a minimum of 2 GiB per device.
"""),
cfg.IntOpt('live_migration_completion_timeout',
default=800,
min=0,
mutable=True,
help="""
Time to wait, in seconds, for migration to successfully complete transferring
data before aborting the operation.
Value is per GiB of guest RAM + disk to be transferred, with lower bound of
a minimum of 2 GiB. Should usually be larger than downtime delay * downtime
steps. Set to 0 to disable timeouts.
Related options:
* live_migration_downtime
* live_migration_downtime_steps
* live_migration_downtime_delay
"""),
cfg.StrOpt('live_migration_timeout_action',
default='abort',
choices=('abort', 'force_complete'),
mutable=True,
help="""
This option will be used to determine what action will be taken against a
VM after ``live_migration_completion_timeout`` expires. By default, the live
migrate operation will be aborted after completion timeout. If it is set to
``force_complete``, the compute service will either pause the VM or trigger
post-copy depending on if post copy is enabled and available
(``live_migration_permit_post_copy`` is set to True).
Related options:
* live_migration_completion_timeout
* live_migration_permit_post_copy
"""),
cfg.BoolOpt('live_migration_permit_post_copy',
default=False,
help="""
This option allows nova to switch an on-going live migration to post-copy
mode, i.e., switch the active VM to the one on the destination node before the
migration is complete, therefore ensuring an upper bound on the memory that
needs to be transferred. Post-copy requires libvirt>=1.3.3 and QEMU>=2.5.0.
When permitted, post-copy mode will be automatically activated if
we reach the timeout defined by ``live_migration_completion_timeout`` and
``live_migration_timeout_action`` is set to 'force_complete'. Note if you
change to no timeout or choose to use 'abort',
i.e. ``live_migration_completion_timeout = 0``, then there will be no
automatic switch to post-copy.
The live-migration force complete API also uses post-copy when permitted. If
post-copy mode is not available, force complete falls back to pausing the VM
to ensure the live-migration operation will complete.
When using post-copy mode, if the source and destination hosts lose network
connectivity, the VM being live-migrated will need to be rebooted. For more
details, please see the Administration guide.
Related options:
* live_migration_permit_auto_converge
* live_migration_timeout_action
"""),
cfg.BoolOpt('live_migration_permit_auto_converge',
default=False,
help="""
This option allows nova to start live migration with auto converge on.
Auto converge throttles down CPU if a progress of on-going live migration
is slow. Auto converge will only be used if this flag is set to True and
post copy is not permitted or post copy is unavailable due to the version
of libvirt and QEMU in use.
Related options:
* live_migration_permit_post_copy
"""),
cfg.StrOpt('snapshot_image_format',
choices=[
('raw', 'RAW disk format'),
('qcow2', 'KVM default disk format'),
('vmdk', 'VMWare default disk format'),
('vdi', 'VirtualBox default disk format'),
],
help="""
Determine the snapshot image format when sending to the image service.
If set, this decides what format is used when sending the snapshot to the
image service. If not set, defaults to same type as source image.
"""),
cfg.BoolOpt('live_migration_with_native_tls',
default=False,
help="""
Use QEMU-native TLS encryption when live migrating.
This option will allow both migration stream (guest RAM plus device
state) *and* disk stream to be transported over native TLS, i.e. TLS
support built into QEMU.
Prerequisite: TLS environment is configured correctly on all relevant
Compute nodes. This means, Certificate Authority (CA), server, client
certificates, their corresponding keys, and their file permissions are
in place, and are validated.
Notes:
* To have encryption for migration stream and disk stream (also called:
"block migration"), ``live_migration_with_native_tls`` is the
preferred config attribute instead of ``live_migration_tunnelled``.
* The ``live_migration_tunnelled`` will be deprecated in the long-term
for two main reasons: (a) it incurs a huge performance penalty; and
(b) it is not compatible with block migration. Therefore, if your
compute nodes have at least libvirt 4.4.0 and QEMU 2.11.0, it is
strongly recommended to use ``live_migration_with_native_tls``.
* The ``live_migration_tunnelled`` and
``live_migration_with_native_tls`` should not be used at the same
time.
* Unlike ``live_migration_tunnelled``, the
``live_migration_with_native_tls`` *is* compatible with block
migration. That is, with this option, NBD stream, over which disks
are migrated to a target host, will be encrypted.
Related options:
``live_migration_tunnelled``: This transports migration stream (but not
disk stream) over libvirtd.
"""),
cfg.StrOpt('disk_prefix',
help="""
Override the default disk prefix for the devices attached to an instance.
If set, this is used to identify a free disk device name for a bus.
Possible values:
* Any prefix which will result in a valid disk device name like 'sda' or 'hda'
for example. This is only necessary if the device names differ to the
commonly known device name prefixes for a virtualization type such as: sd,
xvd, uvd, vd.
Related options:
* ``virt_type``: Influences which device type is used, which determines
the default disk prefix.
"""),
cfg.IntOpt('wait_soft_reboot_seconds',
default=120,
help='Number of seconds to wait for instance to shut down after'
' soft reboot request is made. We fall back to hard reboot'
' if instance does not shutdown within this window.'),
cfg.StrOpt('cpu_mode',
choices=[
('host-model', 'Clone the host CPU feature flags'),
('host-passthrough', 'Use the host CPU model exactly'),
('custom', 'Use the CPU model in ``[libvirt]cpu_models``'),
('none', "Don't set a specific CPU model. For instances with "
"``[libvirt] virt_type`` as KVM/QEMU, the default CPU model from "
"QEMU will be used, which provides a basic set of CPU features "
"that are compatible with most hosts"),
],
help="""
Is used to set the CPU mode an instance should have.
If ``virt_type="kvm|qemu"``, it will default to ``host-model``, otherwise it
will default to ``none``.
Related options:
* ``cpu_models``: This should be set ONLY when ``cpu_mode`` is set to
``custom``. Otherwise, it would result in an error and the instance launch
will fail.
"""),
cfg.ListOpt('cpu_models',
deprecated_name='cpu_model',
default=[],
help="""
An ordered list of CPU models the host supports.
It is expected that the list is ordered so that the more common and less
advanced CPU models are listed earlier. Here is an example:
``SandyBridge,IvyBridge,Haswell,Broadwell``, the latter CPU model's features is
richer that the previous CPU model.
Possible values:
* The named CPU models can be found via ``virsh cpu-models ARCH``, where
ARCH is your host architecture.
Related options:
* ``cpu_mode``: This should be set to ``custom`` ONLY when you want to
configure (via ``cpu_models``) a specific named CPU model. Otherwise, it
would result in an error and the instance launch will fail.
* ``virt_type``: Only the virtualization types ``kvm`` and ``qemu`` use this.
.. note::
Be careful to only specify models which can be fully supported in
hardware.
"""),
cfg.ListOpt(
'cpu_model_extra_flags',
item_type=types.String(
ignore_case=True,
),
default=[],
help="""
Enable or disable guest CPU flags.
To explicitly enable or disable CPU flags, use the ``+flag`` or
``-flag`` notation -- the ``+`` sign will enable the CPU flag for the
guest, while a ``-`` sign will disable it. If neither ``+`` nor ``-``
is specified, the flag will be enabled, which is the default behaviour.
For example, if you specify the following (assuming the said CPU model
and features are supported by the host hardware and software)::
[libvirt]
cpu_mode = custom
cpu_models = Cascadelake-Server
cpu_model_extra_flags = -hle, -rtm, +ssbd, mtrr
Nova will disable the ``hle`` and ``rtm`` flags for the guest; and it
will enable ``ssbd`` and ``mttr`` (because it was specified with neither
``+`` nor ``-`` prefix).
The CPU flags are case-insensitive. In the following example, the
``pdpe1gb`` flag will be disabled for the guest; ``vmx`` and ``pcid``
flags will be enabled::
[libvirt]
cpu_mode = custom
cpu_models = Haswell-noTSX-IBRS
cpu_model_extra_flags = -PDPE1GB, +VMX, pcid
Specifying extra CPU flags is valid in combination with all the three
possible values of ``cpu_mode`` config attribute: ``custom`` (this also
requires an explicit CPU model to be specified via the ``cpu_models``
config attribute), ``host-model``, or ``host-passthrough``.
There can be scenarios where you may need to configure extra CPU flags
even for ``host-passthrough`` CPU mode, because sometimes QEMU may
disable certain CPU features. An example of this is Intel's "invtsc"
(Invariable Time Stamp Counter) CPU flag -- if you need to expose this
flag to a Nova instance, you need to explicitly enable it.
The possible values for ``cpu_model_extra_flags`` depends on the CPU
model in use. Refer to `/usr/share/libvirt/cpu_map/*.xml`` for possible
CPU feature flags for a given CPU model.
A special note on a particular CPU flag: ``pcid`` (an Intel processor
feature that alleviates guest performance degradation as a result of
applying the 'Meltdown' CVE fixes). When configuring this flag with the
``custom`` CPU mode, not all CPU models (as defined by QEMU and libvirt)
need it:
* The only virtual CPU models that include the ``pcid`` capability are
Intel "Haswell", "Broadwell", and "Skylake" variants.
* The libvirt / QEMU CPU models "Nehalem", "Westmere", "SandyBridge",
and "IvyBridge" will _not_ expose the ``pcid`` capability by default,
even if the host CPUs by the same name include it. I.e. 'PCID' needs
to be explicitly specified when using the said virtual CPU models.
The libvirt driver's default CPU mode, ``host-model``, will do the right
thing with respect to handling 'PCID' CPU flag for the guest --
*assuming* you are running updated processor microcode, host and guest
kernel, libvirt, and QEMU. The other mode, ``host-passthrough``, checks
if 'PCID' is available in the hardware, and if so directly passes it
through to the Nova guests. Thus, in context of 'PCID', with either of
these CPU modes (``host-model`` or ``host-passthrough``), there is no
need to use the ``cpu_model_extra_flags``.
Related options:
* cpu_mode
* cpu_models
"""),
cfg.StrOpt('snapshots_directory',
default='$instances_path/snapshots',
help='Location where libvirt driver will store snapshots '
'before uploading them to image service'),
cfg.ListOpt('disk_cachemodes',
default=[],
help="""
Specific cache modes to use for different disk types.
For example: file=directsync,block=none,network=writeback
For local or direct-attached storage, it is recommended that you use
writethrough (default) mode, as it ensures data integrity and has acceptable
I/O performance for applications running in the guest, especially for read
operations. However, caching mode none is recommended for remote NFS storage,
because direct I/O operations (O_DIRECT) perform better than synchronous I/O
operations (with O_SYNC). Caching mode none effectively turns all guest I/O
operations into direct I/O operations on the host, which is the NFS client in
this environment.
Possible cache modes:
* default: "It Depends" -- For Nova-managed disks, ``none``, if the host
file system is capable of Linux's 'O_DIRECT' semantics; otherwise
``writeback``. For volume drivers, the default is driver-dependent:
``none`` for everything except for SMBFS and Virtuzzo (which use
``writeback``).
* none: With caching mode set to none, the host page cache is disabled, but
the disk write cache is enabled for the guest. In this mode, the write
performance in the guest is optimal because write operations bypass the host
page cache and go directly to the disk write cache. If the disk write cache
is battery-backed, or if the applications or storage stack in the guest
transfer data properly (either through fsync operations or file system
barriers), then data integrity can be ensured. However, because the host
page cache is disabled, the read performance in the guest would not be as
good as in the modes where the host page cache is enabled, such as
writethrough mode. Shareable disk devices, like for a multi-attachable block
storage volume, will have their cache mode set to 'none' regardless of
configuration.
* writethrough: With caching set to writethrough mode, the host page cache is
enabled, but the disk write cache is disabled for the guest. Consequently,
this caching mode ensures data integrity even if the applications and storage
stack in the guest do not transfer data to permanent storage properly (either
through fsync operations or file system barriers). Because the host page
cache is enabled in this mode, the read performance for applications running
in the guest is generally better. However, the write performance might be
reduced because the disk write cache is disabled.
* writeback: With caching set to writeback mode, both the host page
cache and the disk write cache are enabled for the guest. Because of
this, the I/O performance for applications running in the guest is
good, but the data is not protected in a power failure. As a result,
this caching mode is recommended only for temporary data where
potential data loss is not a concern.
NOTE: Certain backend disk mechanisms may provide safe
writeback cache semantics. Specifically those that bypass the host
page cache, such as QEMU's integrated RBD driver. Ceph documentation
recommends setting this to writeback for maximum performance while
maintaining data safety.
* directsync: Like "writethrough", but it bypasses the host page cache.
* unsafe: Caching mode of unsafe ignores cache transfer operations
completely. As its name implies, this caching mode should be used only for
temporary data where data loss is not a concern. This mode can be useful for
speeding up guest installations, but you should switch to another caching
mode in production environments.
"""),
cfg.StrOpt('rng_dev_path',
default='/dev/urandom',
help="""
The path to an RNG (Random Number Generator) device that will be used as
the source of entropy on the host. Since libvirt 1.3.4, any path (that
returns random numbers when read) is accepted. The recommended source
of entropy is ``/dev/urandom`` -- it is non-blocking, therefore
relatively fast; and avoids the limitations of ``/dev/random``, which is
a legacy interface. For more details (and comparison between different
RNG sources), refer to the "Usage" section in the Linux kernel API
documentation for ``[u]random``:
http://man7.org/linux/man-pages/man4/urandom.4.html and
http://man7.org/linux/man-pages/man7/random.7.html.
"""),
cfg.ListOpt('hw_machine_type',
help='For qemu or KVM guests, set this option to specify '
'a default machine type per host architecture. '
'You can find a list of supported machine types '
'in your environment by checking the output of the '
':command:`virsh capabilities` command. The format of '
'the value for this config option is '
'``host-arch=machine-type``. For example: '
'``x86_64=machinetype1,armv7l=machinetype2``.'),
cfg.StrOpt('sysinfo_serial',
default='unique',
choices=(
('none', 'A serial number entry is not added to the guest '
'domain xml.'),
('os', 'A UUID serial number is generated from the host '
'``/etc/machine-id`` file.'),
('hardware', 'A UUID for the host hardware as reported by '
'libvirt. This is typically from the host '
'SMBIOS data, unless it has been overridden '
'in ``libvirtd.conf``.'),
('auto', 'Uses the "os" source if possible, else '
'"hardware".'),
('unique', 'Uses instance UUID as the serial number.'),
),
help="""
The data source used to the populate the host "serial" UUID exposed to guest
in the virtual BIOS. All choices except ``unique`` will change the serial when
migrating the instance to another host. Changing the choice of this option will
also affect existing instances on this host once they are stopped and started
again. It is recommended to use the default choice (``unique``) since that will
not change when an instance is migrated. However, if you have a need for
per-host serials in addition to per-instance serial numbers, then consider
restricting flavors via host aggregates.
"""
),
cfg.IntOpt('mem_stats_period_seconds',
default=10,
help='A number of seconds to memory usage statistics period. '
'Zero or negative value mean to disable memory usage '
'statistics.'),
cfg.ListOpt('uid_maps',
default=[],
help='List of uid targets and ranges.'
'Syntax is guest-uid:host-uid:count. '
'Maximum of 5 allowed.'),
cfg.ListOpt('gid_maps',
default=[],
help='List of guid targets and ranges.'
'Syntax is guest-gid:host-gid:count. '
'Maximum of 5 allowed.'),
cfg.IntOpt('realtime_scheduler_priority',
default=1,
help='In a realtime host context vCPUs for guest will run in '
'that scheduling priority. Priority depends on the host '
'kernel (usually 1-99)'),
cfg.ListOpt('enabled_perf_events',
default=[],
help= """
Performance events to monitor and collect statistics for.
This will allow you to specify a list of events to monitor low-level
performance of guests, and collect related statistics via the libvirt
driver, which in turn uses the Linux kernel's ``perf`` infrastructure.
With this config attribute set, Nova will generate libvirt guest XML to
monitor the specified events.
For example, to monitor the count of CPU cycles (total/elapsed) and the
count of cache misses, enable them as follows::
[libvirt]
enabled_perf_events = cpu_clock, cache_misses
Possible values: A string list. The list of supported events can be
found `here`__. Note that Intel CMT events - ``cmt``, ``mbmbt`` and
``mbml`` - are unsupported by recent Linux kernel versions (4.14+) and will be
ignored by nova.
__ https://libvirt.org/formatdomain.html#elementsPerf.
"""),
cfg.IntOpt('num_pcie_ports',
default=0,
min=0,
max=28,
help= """
The number of PCIe ports an instance will get.
Libvirt allows a custom number of PCIe ports (pcie-root-port controllers) a
target instance will get. Some will be used by default, rest will be available
for hotplug use.
By default we have just 1-2 free ports which limits hotplug.
More info: https://github.com/qemu/qemu/blob/master/docs/pcie.txt
Due to QEMU limitations for aarch64/virt maximum value is set to '28'.
Default value '0' moves calculating amount of ports to libvirt.
"""),
cfg.IntOpt('file_backed_memory',
default=0,
min=0,
help="""
Available capacity in MiB for file-backed memory.
Set to 0 to disable file-backed memory.
When enabled, instances will create memory files in the directory specified
in ``/etc/libvirt/qemu.conf``'s ``memory_backing_dir`` option. The default
location is ``/var/lib/libvirt/qemu/ram``.
When enabled, the value defined for this option is reported as the node memory
capacity. Compute node system memory will be used as a cache for file-backed
memory, via the kernel's pagecache mechanism.
.. note::
This feature is not compatible with hugepages.
.. note::
This feature is not compatible with memory overcommit.
Related options:
* ``virt_type`` must be set to ``kvm`` or ``qemu``.
* ``ram_allocation_ratio`` must be set to 1.0.
"""),
cfg.IntOpt('num_memory_encrypted_guests',
default=None,
min=0,
help="""
Maximum number of guests with encrypted memory which can run
concurrently on this compute host.
For now this is only relevant for AMD machines which support SEV
(Secure Encrypted Virtualization). Such machines have a limited
number of slots in their memory controller for storing encryption
keys. Each running guest with encrypted memory will consume one of
these slots.
The option may be reused for other equivalent technologies in the
future. If the machine does not support memory encryption, the option
will be ignored and inventory will be set to 0.
If the machine does support memory encryption and this option is not set,
the driver detects maximum number of SEV guests from the libvirt API which
is available since v8.0.0. Setting this option overrides the detected limit,
unless the given value is not larger than the detected limit.
On the other hand, if an older version of libvirt is used, ``None`` means
an effectively unlimited inventory, i.e. no limit will be imposed by Nova
on the number of SEV guests which can be launched, even though the underlying
hardware will enforce its own limit.
.. note::
It is recommended to read :ref:`the deployment documentation's
section on this option <num_memory_encrypted_guests>` before
deciding whether to configure this setting or leave it at the
default.
Related options:
* :oslo.config:option:`libvirt.virt_type` must be set to ``kvm``.
* It's recommended to consider including ``x86_64=q35`` in
:oslo.config:option:`libvirt.hw_machine_type`; see
:ref:`deploying-sev-capable-infrastructure` for more on this.
"""),
cfg.IntOpt('device_detach_attempts',
default=8,
min=1,
help="""
Maximum number of attempts the driver tries to detach a device in libvirt.
Related options:
* :oslo.config:option:`libvirt.device_detach_timeout`
"""),
cfg.IntOpt('device_detach_timeout',
default=20,
min=1,
help="""
Maximum number of seconds the driver waits for the success or the failure
event from libvirt for a given device detach attempt before it re-trigger the
detach.
Related options:
* :oslo.config:option:`libvirt.device_detach_attempts`
"""),
cfg.IntOpt('tb_cache_size',
min=0,
help="""
Qemu>=5.0.0 bumped the default tb-cache size to 1GiB(from 32MiB) and this
made it difficult to run multiple guest VMs on systems running with lower
memory. With Libvirt>=8.0.0 this config option can be used to configure
lower tb-cache size.
Set it to > 0 to configure tb-cache for guest VMs.
Related options:
* ``compute_driver`` (libvirt)
* ``virt_type`` (qemu)
"""),
cfg.StrOpt('migration_inbound_addr',
default='$my_ip',
help="""
The address used as the migration address for this host.
This option indicates the IP address, hostname, or FQDN which should be used as
the target for cold migration, resize, and evacuate traffic when moving to this
hypervisor. This metadata is then used by the source of the migration traffic
to construct the commands used to copy data (e.g. disk image) to the
destination.
An included "%s" is replaced with the hostname of the migration target
hypervisor.
Related options:
* ``my_ip``
* ``live_migration_inbound_addr``
"""),
]
libvirt_imagebackend_opts = [
cfg.StrOpt('images_type',
default='default',
choices=('raw', 'flat', 'qcow2', 'lvm', 'rbd', 'ploop',
'default'),
help="""
VM Images format.
If default is specified, then use_cow_images flag is used instead of this
one.
Related options:
* compute.use_cow_images
* images_volume_group
* [workarounds]/ensure_libvirt_rbd_instance_dir_cleanup
* compute.force_raw_images
"""),
cfg.StrOpt('images_volume_group',
help="""
LVM Volume Group that is used for VM images, when you specify images_type=lvm
Related options:
* images_type
"""),
cfg.BoolOpt('sparse_logical_volumes',
default=False,
deprecated_for_removal=True,
deprecated_since='18.0.0',
deprecated_reason="""
Sparse logical volumes is a feature that is not tested hence not supported.
LVM logical volumes are preallocated by default. If you want thin provisioning,
use Cinder thin-provisioned volumes.
""",
help="""
Create sparse logical volumes (with virtualsize) if this flag is set to True.
"""),
cfg.StrOpt('images_rbd_pool',
default='rbd',
help='The RADOS pool in which rbd volumes are stored'),
cfg.StrOpt('images_rbd_ceph_conf',
default='', # default determined by librados
help='Path to the ceph configuration file to use'),
cfg.StrOpt('images_rbd_glance_store_name',
default='',
help="""
The name of the Glance store that represents the rbd cluster in use by
this node. If set, this will allow Nova to request that Glance copy an
image from an existing non-local store into the one named by this option
before booting so that proper Copy-on-Write behavior is maintained.
Related options:
* images_type - must be set to ``rbd``
* images_rbd_glance_copy_poll_interval - controls the status poll frequency