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
|
.. role:: since
==============================
Driver capabilities XML format
==============================
.. contents::
Element and attribute overview
------------------------------
As new virtualization engine support gets added to libvirt, and to handle cases
like QEMU supporting a variety of emulations, a query interface has been added
in 0.2.1 allowing to list the set of supported virtualization capabilities on
the host:
::
char * virConnectGetCapabilities (virConnectPtr conn);
The value returned is an XML document listing the virtualization capabilities of
the host and virtualization engine to which ```conn`` is connected. One can test
it using ``virsh`` command line tool command '``capabilities``', it dumps the
XML associated to the current connection.
As can be seen in the `Examples`_, the capabilities XML
consists of the ``capabilities`` element which have exactly one ``host`` child
element to report information on host capabilities, and zero or more ``guest``
element to express the set of architectures the host can run at the moment.
Host capabilities
~~~~~~~~~~~~~~~~~
The ``<host/>`` element consists of the following child elements:
``uuid``
The host UUID.
``cpu``
The host CPU architecture and features.
Note that, while this element contains a ``topology`` sub-element,
the information contained therein is fairly high-level and likely
not very useful when it comes to optimizing guest vCPU placement.
Look into the ``topology`` *element*, described below, for more
detailed information.
``power_management``
whether host is capable of memory suspend, disk hibernation, or hybrid
suspend.
``migration_features``
This element exposes information on the hypervisor's migration capabilities,
like live migration, supported URI transports, and so on.
``topology``
This element describes the host CPU topology in detail.
Management applications may want to use this information when defining new
guests: for example, in order to ensure that all vCPUs are scheduled on
CPUs that are in the same NUMA node or even CPU core.
The ``cells`` sub-element contains a list of NUMA nodes, each one
represented by a single ``cell`` element. Within each ``cell``, a ``cpus``
sub-element contains a list of logical CPUs, each one represented by a
single ``cpu`` element. In both cases, the ``num`` attribute of the
top-level element contains the number of children.
Each ``cpu`` element contains the following attributes:
``id``
CPU identifier. Can be used to refer to it in the context of
`CPU tuning <formatdomain.html#cpu-tuning>`__.
``socket_id``
Identifier for the physical package the CPU is in.
``die_id``
Identifier for the die the CPU is in.
Note that, even if this attribute is present, you might not be able to
define guests with multiple CPU dies.
``cluster_id``
Identifier for the cluster the CPU is in.
Note that, even if this attribute is present, you might not be able to
define guests with multiple CPU clusters.
``core_id``
Identifier for the core the CPU is in.
``siblings``
List of CPUs that are in the same core.
The list will include the current CPU, plus all other CPUs that have the
same values for ``socket_id``, ``die_id``, ``cluster_id`` and ``core_id``.
``secmodel``
To find out default security labels for different security models you need to
parse this element. In contrast with the former elements, this is repeated
for each security model the libvirt daemon currently supports.
Host CPU model and features
^^^^^^^^^^^^^^^^^^^^^^^^^^^
As described previously in this section, libvirt exposes to
users the list of Host CPU features. Libvirt has a special way to
expose this list: Instead of providing the full (and thereby often
very long) set of features, libvirt specifies a CPU model as
baseline and additional features on top of it (as can be seen in
`Examples`_ where the baseline is ``Skylake-Client-noTSX-IBRS``).
The ideal case would be that the baseline CPU model definition matches
exactly the CPU present in the system, and no additional feature is
needed to express the capabilities of the CPU. For example, if you are
running on a Server CPU you bought as ``Icelake`` type, the returned
CPU model name could be ``Icelake-Server``. However, this ideal
situation rarely happens, for two main reasons:
- Manufacturers do not ship a single type of CPU under a given name,
there are various different SKUs with different features under the
same name. Yet it is not practical to have a database listing all of
those variants.
- Some features might be in the hardware but unavailable for various
reasons (BIOS and kernel configuration, disabled for security,
...). One typical example where this situation happens is related to
the `TSX mitigation <https://docs.kernel.org/arch/x86/tsx_async_abort.html>`__.
As a mitigation to the TAA side channel attack, the Linux kernel disables
by default TSX and its 2 features, ``rtm`` and ``hle``. Since many Linux
distributions keep this safer default behavior, these 2 features appear
as missing.
Because for backward compatibility reasons, host capabilities cannot
list features that would need to be removed from the baseline model to
describe the host CPU, libvirt has to often use a rather old CPU
model, for example, ``Broadwell`` rather than ``Icelake``. Therefore,
users *should not* expect the reported CPU model name to have any
implications other than that of a named baseline to build the complete
available feature set of the Host CPU.
`Domain capabilities <formatdomaincaps.html#cpu-configuration>`_ do
not have such limitation, and the ``host-model`` CPU definition would
show the correct CPU model in almost all cases.
Guest capabilities
~~~~~~~~~~~~~~~~~~
While the previous section (`Host capabilities`_) aims at host capabilities,
this one focuses on capabilities available to a guest using a given hypervisor.
The ``<guest/>`` element will typically wrap up the following elements:
``os_type``
This expresses what kind of operating system the hypervisor is able to run.
Possible values are:
``xen``
for XEN PV
``linux``
legacy alias for ``xen``
``xenpvh``
for XEN PVH
``hvm``
Unmodified operating system
``exe``
Container based virtualization
``arch``
This element brings some information on supported guest architecture.
Possible subelements are:
``wordsize``
Size of CPU word in bits, for example 64.
``emulator``
Emulator (device model) path, for use in
`emulator <formatdomain.html#devices>`__ element of domain XML.
``loader``
Loader path, for use in `loader <formatdomain.html#bios-bootloader>`__
element of domain XML.
``machine``
Machine type, for use in
`machine <formatdomain.html#operating-system-booting>`__ attribute of
os/type element in domain XML. For example Xen supports ``xenfv`` for HVM,
``xenpv`` for PV, or ``xenpvh`` for PVH.
``domain``
The ``type`` attribute of this element specifies the type of hypervisor
required to run the domain. Use in
`type <formatdomain.html#element-and-attribute-overview>`__ attribute of
the domain root element.
``features``
This optional element encases possible features that can be used with a guest
of described type. Possible subelements are:
``pae``
If present, 32-bit guests can use PAE address space extensions,
:since:`since 0.4.1`
``nonpae``
If present, 32-bit guests can be run without requiring PAE,
:since:`since 0.4.1`
``ia64_be``
If present, IA64 guests can be run in big-endian mode,
:since:`since 0.4.1`
``acpi``
If this element is present, the ``default`` attribute describes whether
the hypervisor exposes ACPI to the guest by default, and the ``toggle``
attribute describes whether the user can override this default.
:since:`Since 0.4.1`
``apic``
If this element is present, the ``default`` attribute describes whether
the hypervisor exposes APIC to the guest by default, and the ``toggle``
attribute describes whether the user can override this default.
:since:`Since 0.4.1`
``cpuselection``
If this element is present, the hypervisor supports the ``<cpu>`` element
within a domain definition for fine-grained control over the CPU presented
to the guest. :since:`Since 0.7.5`
``deviceboot``
If this element is present, the ``<boot order='...'/>`` element can be
used inside devices, rather than the older boot specification by category.
:since:`Since 0.8.8`
``disksnapshot``
If this element is present, the ``default`` attribute describes whether
creating external disk snapshots is supported. If absent, creating external
snapshots may still be supported, but it requires attempting the API and
checking for an error to find out for sure. :since:`Since 1.2.3`
``externalSnapshot``
If this element is present, the hypervisor supports deleting and
reverting external snapshots including memory state. Support for creation
of external snapshots is reported via the ``disksnapshot`` feature flag.
Management applications can now switch from internal snapshots to external
snapshots. :since:`Since 9.9.0`
Examples
~~~~~~~~
For example, in the case of a 64-bit machine with hardware virtualization
capabilities enabled in the chip and BIOS you will see:
::
<capabilities>
<host>
<uuid>7b55704c-29f4-11b2-a85c-9dc6ff50623f</uuid>
<cpu>
<arch>x86_64</arch>
<model>Skylake-Client-noTSX-IBRS</model>
<vendor>Intel</vendor>
<microcode version='236'/>
<signature family='6' model='142' stepping='12'/>
<counter name='tsc' frequency='2303997000' scaling='no'/>
<topology sockets='1' dies='1' clusters='1' cores='4' threads='2'/>
<maxphysaddr mode='emulate' bits='39'/>
<feature name='ds'/>
<feature name='acpi'/>
<feature name='ss'/>
<feature name='ht'/>
<feature name='tm'/>
<feature name='pbe'/>
<feature name='dtes64'/>
<feature name='monitor'/>
<feature name='ds_cpl'/>
<feature name='vmx'/>
<feature name='smx'/>
<feature name='est'/>
<feature name='tm2'/>
<feature name='xtpr'/>
<feature name='pdcm'/>
<feature name='osxsave'/>
<feature name='tsc_adjust'/>
<feature name='sgx'/>
<feature name='clflushopt'/>
<feature name='intel-pt'/>
<feature name='md-clear'/>
<feature name='stibp'/>
<feature name='arch-capabilities'/>
<feature name='ssbd'/>
<feature name='xsaves'/>
<feature name='sgx1'/>
<feature name='sgx-debug'/>
<feature name='sgx-mode64'/>
<feature name='sgx-provisionkey'/>
<feature name='sgx-tokenkey'/>
<feature name='pdpe1gb'/>
<feature name='invtsc'/>
<feature name='rdctl-no'/>
<feature name='ibrs-all'/>
<feature name='skip-l1dfl-vmentry'/>
<feature name='mds-no'/>
<feature name='tsx-ctrl'/>
<pages unit='KiB' size='4'/>
<pages unit='KiB' size='2048'/>
<pages unit='KiB' size='1048576'/>
</cpu>
<power_management>
<suspend_mem/>
</power_management>
<iommu support='yes'/>
<migration_features>
<live/>
<uri_transports>
<uri_transport>tcp</uri_transport>
<uri_transport>rdma</uri_transport>
</uri_transports>
</migration_features>
<topology>
<cells num='1'>
<cell id='0'>
<memory unit='KiB'>32498112</memory>
<pages unit='KiB' size='4'>6813808</pages>
<pages unit='KiB' size='2048'>2048</pages>
<pages unit='KiB' size='1048576'>1</pages>
<distances>
<sibling id='0' value='10'/>
</distances>
<cpus num='8'>
<cpu id='0' socket_id='0' die_id='0' cluster_id='0' core_id='0' siblings='0,4'/>
<cpu id='1' socket_id='0' die_id='0' cluster_id='0' core_id='1' siblings='1,5'/>
<cpu id='2' socket_id='0' die_id='0' cluster_id='0' core_id='2' siblings='2,6'/>
<cpu id='3' socket_id='0' die_id='0' cluster_id='0' core_id='3' siblings='3,7'/>
<cpu id='4' socket_id='0' die_id='0' cluster_id='0' core_id='0' siblings='0,4'/>
<cpu id='5' socket_id='0' die_id='0' cluster_id='0' core_id='1' siblings='1,5'/>
<cpu id='6' socket_id='0' die_id='0' cluster_id='0' core_id='2' siblings='2,6'/>
<cpu id='7' socket_id='0' die_id='0' cluster_id='0' core_id='3' siblings='3,7'/>
</cpus>
</cell>
</cells>
</topology>
<cache>
<bank id='0' level='3' type='both' size='8' unit='MiB' cpus='0-7'/>
</cache>
<secmodel>
<model>none</model>
<doi>0</doi>
</secmodel>
<secmodel>
<model>dac</model>
<doi>0</doi>
<baselabel type='kvm'>+77:+77</baselabel>
<baselabel type='qemu'>+77:+77</baselabel>
</secmodel>
</host>
<guest>
<os_type>hvm</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine maxCpus='255'>pc-i440fx-7.1</machine>
<machine canonical='pc-i440fx-7.1' maxCpus='255'>pc</machine>
<machine maxCpus='288'>pc-q35-5.2</machine>
<machine maxCpus='255'>pc-i440fx-2.12</machine>
<machine maxCpus='255'>pc-i440fx-2.0</machine>
<machine maxCpus='255'>pc-i440fx-6.2</machine>
<machine maxCpus='288'>pc-q35-4.2</machine>
<machine maxCpus='255'>pc-i440fx-2.5</machine>
<machine maxCpus='255'>pc-i440fx-4.2</machine>
<machine maxCpus='255'>pc-i440fx-5.2</machine>
<machine maxCpus='255' deprecated='yes'>pc-i440fx-1.5</machine>
<machine maxCpus='255'>pc-q35-2.7</machine>
<machine maxCpus='288'>pc-q35-7.1</machine>
<machine canonical='pc-q35-7.1' maxCpus='288'>q35</machine>
<machine maxCpus='255'>pc-i440fx-2.2</machine>
<machine maxCpus='255'>pc-i440fx-2.7</machine>
<machine maxCpus='288'>pc-q35-6.1</machine>
<machine maxCpus='255'>pc-q35-2.4</machine>
<machine maxCpus='288'>pc-q35-2.10</machine>
<machine maxCpus='1'>x-remote</machine>
<machine maxCpus='288'>pc-q35-5.1</machine>
<machine maxCpus='255' deprecated='yes'>pc-i440fx-1.7</machine>
<machine maxCpus='288'>pc-q35-2.9</machine>
<machine maxCpus='255'>pc-i440fx-2.11</machine>
<machine maxCpus='288'>pc-q35-3.1</machine>
<machine maxCpus='255'>pc-i440fx-6.1</machine>
<machine maxCpus='288'>pc-q35-4.1</machine>
<machine maxCpus='255'>pc-i440fx-2.4</machine>
<machine maxCpus='255'>pc-i440fx-4.1</machine>
<machine maxCpus='255'>pc-i440fx-5.1</machine>
<machine maxCpus='255'>pc-i440fx-2.9</machine>
<machine maxCpus='1'>isapc</machine>
<machine maxCpus='255' deprecated='yes'>pc-i440fx-1.4</machine>
<machine maxCpus='255'>pc-q35-2.6</machine>
<machine maxCpus='255'>pc-i440fx-3.1</machine>
<machine maxCpus='288'>pc-q35-2.12</machine>
<machine maxCpus='288'>pc-q35-7.0</machine>
<machine maxCpus='255'>pc-i440fx-2.1</machine>
<machine maxCpus='288'>pc-q35-6.0</machine>
<machine maxCpus='255'>pc-i440fx-2.6</machine>
<machine maxCpus='288'>pc-q35-4.0.1</machine>
<machine maxCpus='255'>pc-i440fx-7.0</machine>
<machine maxCpus='255' deprecated='yes'>pc-i440fx-1.6</machine>
<machine maxCpus='288'>pc-q35-5.0</machine>
<machine maxCpus='288'>pc-q35-2.8</machine>
<machine maxCpus='255'>pc-i440fx-2.10</machine>
<machine maxCpus='288'>pc-q35-3.0</machine>
<machine maxCpus='255'>pc-i440fx-6.0</machine>
<machine maxCpus='288'>pc-q35-4.0</machine>
<machine maxCpus='288'>microvm</machine>
<machine maxCpus='255'>pc-i440fx-2.3</machine>
<machine maxCpus='255'>pc-i440fx-4.0</machine>
<machine maxCpus='255'>pc-i440fx-5.0</machine>
<machine maxCpus='255'>pc-i440fx-2.8</machine>
<machine maxCpus='288'>pc-q35-6.2</machine>
<machine maxCpus='255'>pc-q35-2.5</machine>
<machine maxCpus='255'>pc-i440fx-3.0</machine>
<machine maxCpus='288'>pc-q35-2.11</machine>
<domain type='qemu'/>
<domain type='kvm'/>
</arch>
<features>
<acpi default='on' toggle='yes'/>
<apic default='on' toggle='no'/>
<cpuselection/>
<deviceboot/>
<disksnapshot default='on' toggle='no'/>
<externalSnapshot/>
</features>
</guest>
</capabilities>
|
