xen-project/xen
1
0 Fork 1
mirror of https://github.com/xen-project/xen.git synced 2026-10-29 18:50:05 +01:00
Code Issues Activity
Files
9239a90ecd4789e73dcb2b67e07db4cfec580a9e
xen/docs/man/xl.conf.5.pod
T
George Dunlap f2ae59bc4b Rationalize max_grant_frames and max_maptrack_frames handling 
Xen used to have single, system-wide limits for the number of grant
frames and maptrack frames a guest was allowed to create. Increasing
or decreasing this single limit on the Xen command-line would change
the limit for all guests on the system.

Later, per-domain limits for these values was created. The system-wide
limits became strict limits: domains could not be created with higher
limits, but could be created with lower limits. However, that change
also introduced a range of different "default" values into various
places in the toolstack:

- The python libxc bindings hard-coded these values to 32 and 1024,
  respectively
- The libxl default values are 32 and 1024 respectively.
- xl will use the libxl default for maptrack, but does its own default
  calculation for grant frames: either 32 or 64, based on the max
  possible mfn.

These defaults interact poorly with the hypervisor command-line limit:

- The hypervisor command-line limit cannot be used to raise the limit
  for all guests anymore, as the default in the toolstack will
  effectively override this.
- If you use the hypervisor command-line limit to *reduce* the limit,
  then the "default" values generated by the toolstack are too high,
  and all guest creations will fail.

In other words, the toolstack defaults require any change to be
effected by having the admin explicitly specify a new value in every
guest.

In order to address this, have grant_table_init treat negative values
for max_grant_frames and max_maptrack_frames as instructions to use the
system-wide default, and have all the above toolstacks default to passing
-1 unless a different value is explicitly configured.

This restores the old behavior in that changing the hypervisor command-line
option can change the behavior for all guests, while retaining the ability
to set per-guest values.  It also removes the bug that reducing the
system-wide max will cause all domains without explicit limits to fail.

NOTE: - The Ocaml bindings require the caller to always specify a value,
        and the code to start a xenstored stubdomain hard-codes these to 4
	and 128 respectively; this behavour will not be modified.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
2019-11-29 21:43:49 +00:00

220 lines
5.9 KiB
INI
Raw Blame History

=head1 NAME
/etc/xen/xl.conf - XL Global/Host Configuration
=head1 DESCRIPTION
The F<xl.conf> file allows configuration of hostwide C<xl> toolstack
options.
For details of per-domain configuration options please see
L<xl.cfg(5)>.
=head1 SYNTAX
The config file consists of a series of C<KEY=VALUE> pairs.
A value C<VALUE> is one of:
=over 4
=item B<"STRING">
A string, surrounded by either single or double quotes.
=item B<NUMBER>
A number, in either decimal, octal (using a C<0> prefix) or
hexadecimal (using an C<0x> prefix).
=item B<BOOLEAN>
A C<NUMBER> interpreted as C<False> (C<0>) or C<True> (any other
value).
=item B<[ VALUE, VALUE, ... ]>
A list of C<VALUES> of the above types. Lists are homogeneous and are
not nested.
=back
The semantics of each C<KEY> defines which form of C<VALUE> is required.
=head1 OPTIONS
=over 4
=item B<autoballoon="off"|"on"|"auto">
If set to "on" then C<xl> will automatically reduce the amount of
memory assigned to domain 0 in order to free memory for new domains.
If set to "off" then C<xl> will not automatically reduce the amount of
domain 0 memory.
If set to "auto" then auto-ballooning will be disabled if the
C<dom0_mem> option was provided on the Xen command line.
You are strongly recommended to set this to C<"off"> (or C<"auto">) if
you use the C<dom0_mem> hypervisor command line to reduce the amount
of memory given to domain 0 by default.
Default: C<"auto">
=item B<run_hotplug_scripts=BOOLEAN>
If disabled hotplug scripts will be called from udev, as it used to
be in the previous releases. With the default option, hotplug scripts
will be launched by xl directly.
Default: C<1>
=item B<lockfile="PATH">
Sets the path to the lock file used by xl to serialise certain
operations (primarily domain creation).
Default: C</var/lock/xl>
=item B<max_grant_frames=NUMBER>
Sets the default value for the C<max_grant_frames> domain config value.
Default: value of Xen command line B<gnttab_max_frames> parameter (or its
default value if unspecified).
=item B<max_maptrack_frames=NUMBER>
Sets the default value for the C<max_maptrack_frames> domain config value.
Default: value of Xen command line B<gnttab_max_maptrack_frames>
parameter (or its default value if unspecified).
=item B<vif.default.script="PATH">
Configures the default hotplug script used by virtual network devices.
The old B<vifscript> option is deprecated and should not be used.
Default: C</etc/xen/scripts/vif-bridge>
=item B<vif.default.bridge="NAME">
Configures the default bridge to set for virtual network devices.
The old B<defaultbridge> option is deprecated and should not be used.
Default: C<xenbr0>
=item B<vif.default.backend="NAME">
Configures the default backend to set for virtual network devices.
Default: C<0>
=item B<vif.default.gatewaydev="NAME">
Configures the default gateway device to set for virtual network devices.
Default: C<None>
=item B<remus.default.netbufscript="PATH">
Configures the default script used by Remus to setup network buffering.
Default: C</etc/xen/scripts/remus-netbuf-setup>
=item B<colo.default.proxyscript="PATH">
Configures the default script used by COLO to setup colo-proxy.
Default: C</etc/xen/scripts/colo-proxy-setup>
=item B<output_format="json|sxp">
Configures the default output format used by xl when printing "machine
readable" information. The default is to use the C<JSON>
L<https://www.json.org/> syntax. However for compatibility with the
previous C<xm> toolstack this can be configured to use the old C<SXP>
(S-Expression-like) syntax instead.
Default: C<json>
=item B<blkdev_start="NAME">
Configures the name of the first block device to be used for temporary
block device allocations by the toolstack.
The default choice is "xvda".
=item B<claim_mode=BOOLEAN>
If this option is enabled then when a guest is created there will be an
guarantee that there is memory available for the guest.
The self-balloon mechanism can deflate/inflate the balloon
quickly and the amount of free memory (which C<xl info> can show) is
stale the moment it is printed. When claim is enabled a reservation for
the amount of memory (see 'memory' in xl.conf(5)) is set, which is then
reduced as the domain's memory is populated and eventually reaches zero.
The free memory in C<xl info> is the combination of the hypervisor's
free heap memory minus the outstanding claims value.
If the reservation cannot be meet the guest creation fails immediately
instead of taking seconds/minutes (depending on the size of the guest)
while the guest is populated.
Default: C<1>
=over 4
=item C<0>
No claim is made. Memory population during guest creation will be
attempted as normal and may fail due to memory exhaustion.
=item C<1>
Free memory as reported by the hypervisor is used for
calculating whether there is enough memory free to launch a guest.
This guarantees immediate feedback whether the guest can be launched due
to memory exhaustion (which can take a long time to find out if launching
massively huge guests).
=back
=item B<vm.cpumask>="CPULIST"
=item B<vm.hvm.cpumask>="CPULIST"
=item B<vm.pv.cpumask>="CPULIST"
Global masks that are applied when creating guests and pinning vcpus
to indicate which cpus they are allowed to run on. Specifically,
C<vm.cpumask> applies to all guest types, C<vm.hvm.cpumask> applies to
both HVM and PVH guests and C<vm.pv.cpumask> applies to PV guests.
The hard affinity of guest's vcpus are logical-AND'ed with respective
masks. If the resulting affinity mask is empty, operation will fail.
Use --ignore-global-affinity-masks to skip applying global masks.
The default value for these masks are all 1's, i.e. all cpus are allowed.
Due to bug(s), these options may not interact well with other options
concerning CPU affinity. One example is CPU pools. Users should always double
check that the required affinity has taken effect.
=back
=head1 SEE ALSO
=over 4
=item L<xl(1)>
=item L<xl.cfg(5)>
=item https://www.json.org/
=back
Reference in new issue View Git Blame Copy Permalink