../config/Docs.mk
man/xl.cfg.5.pod
man/xl.1.pod
+man/xl-disk-configuration.5.pod
+man/xl-network-configuration.5.pod
+man/xl.conf.5.pod
])
AC_CONFIG_AUX_DIR([../])
+++ /dev/null
-=head1 NAME
-
-xl-disk-configuration - XL Disk Configuration Syntax
-
-=head1 SYNTAX
-
-This document specifies the xl config file format disk configuration
-option. It has the following form:
-
- disk = [ 'DISKSPEC', 'DISKSPEC', ... ]
-
-where each C<DISKSPEC> is in this form:
-
- [<key>=<value>|<flag>,]*,
- [<target>, [<format>, [<vdev>, [<access>]]]],
- [<key>=<value>|<flag>,]*
- [target=<target>]
-
-For example, these strings are equivalent:
-
- /dev/vg/guest-volume,,hda
- /dev/vg/guest-volume,raw,hda,rw
- format=raw, vdev=hda, access=rw, target=/dev/vg/guest-volume
- raw:/dev/vg/guest-volume,hda,w (deprecated, see below)
-
-As are these:
-
- /root/image.iso,,hdc,cdrom
- /root/image.iso,,hdc,,cdrom
- /root/image.iso,raw,hdc,devtype=cdrom
- format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/root/image.iso
- raw:/root/image.iso,hdc:cdrom,ro (deprecated, see below)
-
-These might be specified in the domain config file like this:
-
- disk = [ '/dev/vg/guest-volume,,hda', '/root/image.iso,,hdc,cdrom' ]
-
-
-More formally, the string is a series of comma-separated keyword/value
-pairs, flags and positional parameters. Parameters which are not bare
-keywords and which do not contain "=" symbols are assigned to the
-so-far-unspecified positional parameters, in the order below. The
-positional parameters may also be specified explicitly by name.
-
-Each parameter may be specified at most once, either as a positional
-parameter or a named parameter. Default values apply if the parameter
-is not specified, or if it is specified with an empty value (whether
-positionally or explicitly).
-
-Whitespace may appear before each parameter and will be ignored.
-
-=head1 Positional Parameters
-
-=over 4
-
-=item B<target>
-
-=over 4
-
-=item Description
-
-Block device or image file path. When this is used as a path, F</dev>
-will be prepended if the path doesn't start with a '/'.
-
-=item Supported values
-
-N/A
-
-=item Deprecated values
-
-N/A
-
-=item Default value
-
-None. While a path is provided in most cases there is an exception:
-for a cdrom device, lack of this attribute would imply an empty cdrom
-drive.
-
-=item Special syntax
-
-When this parameter is specified by name, ie with the C<target=>
-syntax in the configuration file, it consumes the whole rest of the
-C<DISKSPEC> including trailing whitespaces. Therefore in that case
-it must come last. This is permissible even if an empty value for
-the target was already specified as a positional parameter. This
-is the only way to specify a target string containing metacharacters
-such as commas and (in some cases) colons, which would otherwise be
-misinterpreted.
-
-Future parameter and flag names will start with an ascii letter and
-contain only ascii alphanumerics, hyphens and underscores, and will
-not be legal as vdevs. Targets which might match that syntax
-should not be specified as positional parameters.
-
-=back
-
-=item B<format>
-
-=over 4
-
-=item Description
-
-Specifies the format of image file.
-
-=item Supported values
-
-raw, qcow, qcow2, vhd, qed
-
-=item Deprecated values
-
-None
-
-=item Default value
-
-raw
-
-=back
-
-=item B<vdev>
-
-=over 4
-
-=item Description
-
-Virtual device as seen by the guest (also referred to as guest drive
-designation in some specifications). See L<xen-vbd-interface(7)>.
-
-=item Supported values
-
-hd[x], xvd[x], sd[x] etc. Please refer to the above specification for
-further details.
-
-=item Deprecated values
-
-None
-
-=item Default Value
-
-None, this parameter is mandatory.
-
-=back
-
-=item B<access>
-
-=over 4
-
-=item Description
-
-Specified access control information. Whether or not the block device is
-provided to the guest in read-only or read-write mode depends on this
-attribute.
-
-=item Supported values
-
-C<ro>, C<r> (specifies read-only)
-
-C<rw>, C<w> (specifies read/write)
-
-=item Deprecated values
-
-None
-
-=item Default value
-
-C<rw> unless devtype=cdrom, in which case C<r>
-
-=back
-
-=back
-
-=head1 Other Parameters And Flags
-
-=over 4
-
-=item B<devtype>=I<DEVTYPE>
-
-=over 4
-
-=item Description
-
-Qualifies virtual device type.
-
-=item Supported values
-
-cdrom
-
-=item Deprecated values
-
-None
-
-=item Mandatory
-
-No
-
-=back
-
-=item B<cdrom>
-
-Convenience alias for "devtype=cdrom".
-
-
-=item B<backend>=I<DOMAIN-NAME>
-
-=over 4
-
-=item Description
-
-Designates a backend domain for the device
-
-=item Supported values
-
-Valid domain names
-
-=item Mandatory
-
-No
-
-=back
-
-Specifies the backend domain which this device should attach to. This
-defaults to domain 0. Specifying another domain requires setting up a
-driver domain which is outside the scope of this document.
-
-
-=item B<backendtype>=I<TYPE>
-
-=over 4
-
-=item Description
-
-Specifies the backend implementation to use
-
-=item Supported values
-
-phy, qdisk
-
-=item Mandatory
-
-No
-
-=item Default value
-
-Automatically determine which backend to use.
-
-=back
-
-This does not affect the guest's view of the device. It controls
-which software implementation of the Xen backend driver is used.
-
-Not all backend drivers support all combinations of other options.
-For example, "phy" does not support formats other than "raw".
-Normally this option should not be specified, in which case libxl will
-automatically determine the most suitable backend.
-
-
-=item B<script>=I<SCRIPT>
-
-Specifies that B<target> is not a normal host path, but rather
-information to be interpreted by the executable program I<SCRIPT>,
-(looked for in F</etc/xen/scripts>, if it doesn't contain a slash).
-
-These scripts are normally called "block-I<SCRIPT>".
-
-
-=item B<direct-io-safe>
-
-=over 4
-
-=item Description
-
-Disables non-O_DIRECT workaround
-
-=item Supported values
-
-absent, present
-
-=item Mandatory
-
-No
-
-=item Default value
-
-absent (workaround may be enabled)
-
-=back
-
-There is a memory lifetime bug in some driver domain (dom0) kernels
-which can cause crashes when using O_DIRECT. The bug occurs due to a
-mismatch between the backend-visible lifetime of pages used for the
-Xen PV network protocol and that expected by the backend kernel's
-networking subsystem. This can cause crashes when using certain
-backends with certain underlying storage.
-
-See:
- L<https://lists.xenproject.org/archives/html/xen-devel/2012-12/msg01154.html>
-
-For this reason, (this version of) the Xen libxl toolstack disables
-O_DIRECT when using the qemu-based Xen PV backend (C<qdisk>).
-
-However, this workaround has performance and scaling implications, and
-it is only necessary if the underlying device is a network filesystem.
-If the underlying device is not, then it is good to disable it; that
-is what this option is for.
-
-This option simply requests that the workaround be disabled. (However,
-not all backends versions which use the workaround understand this
-option, so this is on a best effort basis.)
-
-It's important to note that if you are storing the VM disk on a
-network filesystem or a network block device (NFS or ISCSI) it might
-not be safe to use this option. Otherwise specifying it is safe and
-can give better performances.
-
-If in the future the bug is fixed properly this option will then be
-silently ignored.
-
-
-=item B<discard> / B<no-discard>
-
-=over 4
-
-=item Description
-
-Request that backend advertise discard support to frontend
-
-=item Supported values
-
-discard, no-discard
-
-=item Mandatory
-
-No
-
-=item Default value
-
-discard
-
-=back
-
-An advisory setting for the backend driver, specifying whether to
-advertise discard support (TRIM, UNMAP) to the frontend. The real
-benefit of this option is to be able to force it off rather than on. It
-can be used to disable "hole punching" for file based backends which
-were intentionally created non-sparse to avoid fragmentation of the
-file.
-
-=back
-
-
-=head1 COLO Parameters
-
-=over 4
-
-=item B<colo>
-
-Enable COLO HA for disk. For better understanding block replication on
-QEMU, please refer to: L<https://wiki.qemu.org/Features/BlockReplication>
-Note that the COLO configuration settings should be considered unstable.
-They may change incompatibly in future versions of Xen.
-
-
-=item B<colo-host>
-
-=over 4
-
-=item Description
-
-Secondary host's address
-
-=item Mandatory
-
-Yes when COLO enabled
-
-=back
-
-=item B<colo-port>
-
-=over 4
-
-=item Description
-
-Secondary port. We will run a nbd server on secondary host,
-and the nbd server will listen this port.
-
-=item Mandatory
-
-Yes when COLO enabled
-
-=back
-
-=item B<colo-export>
-
-=over 4
-
-=item Description
-
-We will run a nbd server on secondary host, exportname is
-the nbd server's disk export name.
-
-=item Mandatory
-
-Yes when COLO enabled
-
-=back
-
-=item B<active-disk>
-
-=over 4
-
-=item Description
-
-This is used by secondary. Secondary guest's write will be buffered in this
-disk.
-
-=item Mandatory
-
-Yes when COLO enabled
-
-=back
-
-=item B<hidden-disk>
-
-=over 4
-
-=item Description
-
-This is used by secondary. It buffers the original content that is modified
-by the primary VM.
-
-=item Mandatory
-
-Yes when COLO enabled
-
-=back
-
-=back
-
-
-=head1 Deprecated Parameters, Prefixes And Syntaxes
-
-Deprecated forms are acceptable and are intended work compatibly with
-xend and xl from xen 4.1. In future they may print a warning.
-Support for deprecated parameters and syntaxes are likely to be
-dropped in future versions of xl.
-
-There is support for a deprecated old syntax for C<DISKSPEC>:
-
- [<format>:][<target>],<vdev>[:<devtype>],<access> (deprecated)
-
-This syntax also supports deprecated prefixes, described below. These
-are found prepended to the format parameter - eg C<tap:aio:qcow:>.
-
-=over 4
-
-=item B<format>
-
-=over 4
-
-=item Description
-
-Specifies the format (deprecated)
-
-=item Supported values
-
-raw: qcow2: vhd:
-
-=back
-
-In xend and old versions of libxl it was necessary to specify the
-format with a prefix. For compatibility, these three prefixes are
-recognised as specifying the corresponding format. They are
-equivalent to C<format=FORMAT> or the specification of B<format>
-(without a colon) as a positional parameter.
-
-
-=item B<script>
-
-=over 4
-
-=item Description
-
-Specifies the script (deprecated)
-
-=item Supported values
-
-iscsi: nbd: enbd: drbd:
-
-=back
-
-In xend and old versions of libxl it was necessary to specify the
-"script" (see above) with a prefix. For compatibility, these four
-prefixes are recognised as specifying the corresponding script. They
-are equivalent to C<script=block-SCRIPT>.
-
-
-=item B<deprecated-prefix>
-
-=over 4
-
-=item Description
-
-Deprecated prefix, ignored
-
-=item Supported values
-
-tapdisk: tap2: aio: ioemu: file: phy:
-
-=back
-
-Various prefixes were required by xend and older versions of libxl to
-make the block devices work. In some cases these options would
-override the backend type, but in other cases they would be ignored in
-favour of "making it work"; in yet other cases it would be necessary
-to specify several of these, for example:
-
- tap:aio:/some/path...
-
-All of these prefixes are now stripped and ignored.
-
-=back
-
-=head2 Missing format and empty target
-
-The following syntax is also supported:
-
- ,<vdev>:<devtype>,<access> (deprecated)
-
-This is solely for compatibility with xend's syntax for empty cdroms,
-which is (for example) C<,hdc:cdrom,r>.
--- /dev/null
+=head1 NAME
+
+xl-disk-configuration - XL Disk Configuration Syntax
+
+=head1 SYNTAX
+
+This document specifies the xl config file format disk configuration
+option. It has the following form:
+
+ disk = [ 'DISKSPEC', 'DISKSPEC', ... ]
+
+where each C<DISKSPEC> is in this form:
+
+ [<key>=<value>|<flag>,]*,
+ [<target>, [<format>, [<vdev>, [<access>]]]],
+ [<key>=<value>|<flag>,]*
+ [target=<target>]
+
+For example, these strings are equivalent:
+
+ /dev/vg/guest-volume,,hda
+ /dev/vg/guest-volume,raw,hda,rw
+ format=raw, vdev=hda, access=rw, target=/dev/vg/guest-volume
+ raw:/dev/vg/guest-volume,hda,w (deprecated, see below)
+
+As are these:
+
+ /root/image.iso,,hdc,cdrom
+ /root/image.iso,,hdc,,cdrom
+ /root/image.iso,raw,hdc,devtype=cdrom
+ format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/root/image.iso
+ raw:/root/image.iso,hdc:cdrom,ro (deprecated, see below)
+
+These might be specified in the domain config file like this:
+
+ disk = [ '/dev/vg/guest-volume,,hda', '/root/image.iso,,hdc,cdrom' ]
+
+
+More formally, the string is a series of comma-separated keyword/value
+pairs, flags and positional parameters. Parameters which are not bare
+keywords and which do not contain "=" symbols are assigned to the
+so-far-unspecified positional parameters, in the order below. The
+positional parameters may also be specified explicitly by name.
+
+Each parameter may be specified at most once, either as a positional
+parameter or a named parameter. Default values apply if the parameter
+is not specified, or if it is specified with an empty value (whether
+positionally or explicitly).
+
+Whitespace may appear before each parameter and will be ignored.
+
+=head1 Positional Parameters
+
+=over 4
+
+=item B<target>
+
+=over 4
+
+=item Description
+
+Block device or image file path. When this is used as a path, F</dev>
+will be prepended if the path doesn't start with a '/'.
+
+=item Supported values
+
+N/A
+
+=item Deprecated values
+
+N/A
+
+=item Default value
+
+None. While a path is provided in most cases there is an exception:
+for a cdrom device, lack of this attribute would imply an empty cdrom
+drive.
+
+=item Special syntax
+
+When this parameter is specified by name, ie with the C<target=>
+syntax in the configuration file, it consumes the whole rest of the
+C<DISKSPEC> including trailing whitespaces. Therefore in that case
+it must come last. This is permissible even if an empty value for
+the target was already specified as a positional parameter. This
+is the only way to specify a target string containing metacharacters
+such as commas and (in some cases) colons, which would otherwise be
+misinterpreted.
+
+Future parameter and flag names will start with an ascii letter and
+contain only ascii alphanumerics, hyphens and underscores, and will
+not be legal as vdevs. Targets which might match that syntax
+should not be specified as positional parameters.
+
+=back
+
+=item B<format>
+
+=over 4
+
+=item Description
+
+Specifies the format of image file.
+
+=item Supported values
+
+raw, qcow, qcow2, vhd, qed
+
+=item Deprecated values
+
+None
+
+=item Default value
+
+raw
+
+=back
+
+=item B<vdev>
+
+=over 4
+
+=item Description
+
+Virtual device as seen by the guest (also referred to as guest drive
+designation in some specifications). See L<xen-vbd-interface(7)>.
+
+=item Supported values
+
+hd[x], xvd[x], sd[x] etc. Please refer to the above specification for
+further details.
+
+=item Deprecated values
+
+None
+
+=item Default Value
+
+None, this parameter is mandatory.
+
+=back
+
+=item B<access>
+
+=over 4
+
+=item Description
+
+Specified access control information. Whether or not the block device is
+provided to the guest in read-only or read-write mode depends on this
+attribute.
+
+=item Supported values
+
+C<ro>, C<r> (specifies read-only)
+
+C<rw>, C<w> (specifies read/write)
+
+=item Deprecated values
+
+None
+
+=item Default value
+
+C<rw> unless devtype=cdrom, in which case C<r>
+
+=back
+
+=back
+
+=head1 Other Parameters And Flags
+
+=over 4
+
+=item B<devtype>=I<DEVTYPE>
+
+=over 4
+
+=item Description
+
+Qualifies virtual device type.
+
+=item Supported values
+
+cdrom
+
+=item Deprecated values
+
+None
+
+=item Mandatory
+
+No
+
+=back
+
+=item B<cdrom>
+
+Convenience alias for "devtype=cdrom".
+
+
+=item B<backend>=I<DOMAIN-NAME>
+
+=over 4
+
+=item Description
+
+Designates a backend domain for the device
+
+=item Supported values
+
+Valid domain names
+
+=item Mandatory
+
+No
+
+=back
+
+Specifies the backend domain which this device should attach to. This
+defaults to domain 0. Specifying another domain requires setting up a
+driver domain which is outside the scope of this document.
+
+
+=item B<backendtype>=I<TYPE>
+
+=over 4
+
+=item Description
+
+Specifies the backend implementation to use
+
+=item Supported values
+
+phy, qdisk
+
+=item Mandatory
+
+No
+
+=item Default value
+
+Automatically determine which backend to use.
+
+=back
+
+This does not affect the guest's view of the device. It controls
+which software implementation of the Xen backend driver is used.
+
+Not all backend drivers support all combinations of other options.
+For example, "phy" does not support formats other than "raw".
+Normally this option should not be specified, in which case libxl will
+automatically determine the most suitable backend.
+
+
+=item B<script>=I<SCRIPT>
+
+Specifies that B<target> is not a normal host path, but rather
+information to be interpreted by the executable program I<SCRIPT>,
+(looked for in F<@XEN_SCRIPT_DIR@>, if it doesn't contain a slash).
+
+These scripts are normally called "block-I<SCRIPT>".
+
+
+=item B<direct-io-safe>
+
+=over 4
+
+=item Description
+
+Disables non-O_DIRECT workaround
+
+=item Supported values
+
+absent, present
+
+=item Mandatory
+
+No
+
+=item Default value
+
+absent (workaround may be enabled)
+
+=back
+
+There is a memory lifetime bug in some driver domain (dom0) kernels
+which can cause crashes when using O_DIRECT. The bug occurs due to a
+mismatch between the backend-visible lifetime of pages used for the
+Xen PV network protocol and that expected by the backend kernel's
+networking subsystem. This can cause crashes when using certain
+backends with certain underlying storage.
+
+See:
+ L<https://lists.xenproject.org/archives/html/xen-devel/2012-12/msg01154.html>
+
+For this reason, (this version of) the Xen libxl toolstack disables
+O_DIRECT when using the qemu-based Xen PV backend (C<qdisk>).
+
+However, this workaround has performance and scaling implications, and
+it is only necessary if the underlying device is a network filesystem.
+If the underlying device is not, then it is good to disable it; that
+is what this option is for.
+
+This option simply requests that the workaround be disabled. (However,
+not all backends versions which use the workaround understand this
+option, so this is on a best effort basis.)
+
+It's important to note that if you are storing the VM disk on a
+network filesystem or a network block device (NFS or ISCSI) it might
+not be safe to use this option. Otherwise specifying it is safe and
+can give better performances.
+
+If in the future the bug is fixed properly this option will then be
+silently ignored.
+
+
+=item B<discard> / B<no-discard>
+
+=over 4
+
+=item Description
+
+Request that backend advertise discard support to frontend
+
+=item Supported values
+
+discard, no-discard
+
+=item Mandatory
+
+No
+
+=item Default value
+
+discard
+
+=back
+
+An advisory setting for the backend driver, specifying whether to
+advertise discard support (TRIM, UNMAP) to the frontend. The real
+benefit of this option is to be able to force it off rather than on. It
+can be used to disable "hole punching" for file based backends which
+were intentionally created non-sparse to avoid fragmentation of the
+file.
+
+=back
+
+
+=head1 COLO Parameters
+
+=over 4
+
+=item B<colo>
+
+Enable COLO HA for disk. For better understanding block replication on
+QEMU, please refer to: L<https://wiki.qemu.org/Features/BlockReplication>
+Note that the COLO configuration settings should be considered unstable.
+They may change incompatibly in future versions of Xen.
+
+
+=item B<colo-host>
+
+=over 4
+
+=item Description
+
+Secondary host's address
+
+=item Mandatory
+
+Yes when COLO enabled
+
+=back
+
+=item B<colo-port>
+
+=over 4
+
+=item Description
+
+Secondary port. We will run a nbd server on secondary host,
+and the nbd server will listen this port.
+
+=item Mandatory
+
+Yes when COLO enabled
+
+=back
+
+=item B<colo-export>
+
+=over 4
+
+=item Description
+
+We will run a nbd server on secondary host, exportname is
+the nbd server's disk export name.
+
+=item Mandatory
+
+Yes when COLO enabled
+
+=back
+
+=item B<active-disk>
+
+=over 4
+
+=item Description
+
+This is used by secondary. Secondary guest's write will be buffered in this
+disk.
+
+=item Mandatory
+
+Yes when COLO enabled
+
+=back
+
+=item B<hidden-disk>
+
+=over 4
+
+=item Description
+
+This is used by secondary. It buffers the original content that is modified
+by the primary VM.
+
+=item Mandatory
+
+Yes when COLO enabled
+
+=back
+
+=back
+
+
+=head1 Deprecated Parameters, Prefixes And Syntaxes
+
+Deprecated forms are acceptable and are intended work compatibly with
+xend and xl from xen 4.1. In future they may print a warning.
+Support for deprecated parameters and syntaxes are likely to be
+dropped in future versions of xl.
+
+There is support for a deprecated old syntax for C<DISKSPEC>:
+
+ [<format>:][<target>],<vdev>[:<devtype>],<access> (deprecated)
+
+This syntax also supports deprecated prefixes, described below. These
+are found prepended to the format parameter - eg C<tap:aio:qcow:>.
+
+=over 4
+
+=item B<format>
+
+=over 4
+
+=item Description
+
+Specifies the format (deprecated)
+
+=item Supported values
+
+raw: qcow2: vhd:
+
+=back
+
+In xend and old versions of libxl it was necessary to specify the
+format with a prefix. For compatibility, these three prefixes are
+recognised as specifying the corresponding format. They are
+equivalent to C<format=FORMAT> or the specification of B<format>
+(without a colon) as a positional parameter.
+
+
+=item B<script>
+
+=over 4
+
+=item Description
+
+Specifies the script (deprecated)
+
+=item Supported values
+
+iscsi: nbd: enbd: drbd:
+
+=back
+
+In xend and old versions of libxl it was necessary to specify the
+"script" (see above) with a prefix. For compatibility, these four
+prefixes are recognised as specifying the corresponding script. They
+are equivalent to C<script=block-SCRIPT>.
+
+
+=item B<deprecated-prefix>
+
+=over 4
+
+=item Description
+
+Deprecated prefix, ignored
+
+=item Supported values
+
+tapdisk: tap2: aio: ioemu: file: phy:
+
+=back
+
+Various prefixes were required by xend and older versions of libxl to
+make the block devices work. In some cases these options would
+override the backend type, but in other cases they would be ignored in
+favour of "making it work"; in yet other cases it would be necessary
+to specify several of these, for example:
+
+ tap:aio:/some/path...
+
+All of these prefixes are now stripped and ignored.
+
+=back
+
+=head2 Missing format and empty target
+
+The following syntax is also supported:
+
+ ,<vdev>:<devtype>,<access> (deprecated)
+
+This is solely for compatibility with xend's syntax for empty cdroms,
+which is (for example) C<,hdc:cdrom,r>.
+++ /dev/null
-=encoding utf8
-
-=head1 NAME
-
-xl-network-configuration - XL Network Configuration Syntax
-
-
-=head1 SYNTAX
-
-This document specifies the xl config file format vif configuration
-option. It has the following form:
-
- vif = [ '<vifspec>', '<vifspec>', ... ]
-
-where each vifspec is in this form:
-
- [<key>=<value>|<flag>,]
-
-For example:
-
- 'mac=00:16:3E:74:3d:76,model=rtl8139,bridge=xenbr0'
- 'mac=00:16:3E:74:34:32'
- '' # The empty string
-
-These might be specified in the domain config file like this:
-
- vif = [ 'mac=00:16:3E:74:34:32', 'mac=00:16:3e:5f:48:e4,bridge=xenbr1' ]
-
-More formally, the string is a series of comma-separated keyword/value
-pairs. All keywords are optional.
-
-Each device has a C<DEVID> which is its index within the vif list, starting from 0.
-
-
-=head1 Keywords
-
-
-=head2 mac
-
-If specified then this option specifies the MAC address inside the
-guest of this VIF device. The value is a 48-bit number represented as
-six groups of two hexadecimal digits, separated by colons (:).
-
-The default if this keyword is not specified is to be automatically
-generate a MAC address inside the space assigned to Xen's
-L<Organizationally Unique Identifier|https://en.wikipedia.org/wiki/Organizationally_Unique_Identifier> (00:16:3e).
-
-If you are choosing a MAC address then it is strongly recommend to
-follow one of the following strategies:
-
-=over
-
-=item *
-
-Generate a random sequence of 6 byte, set the locally administered
-bit (bit 2 of the first byte) and clear the multicast bit (bit 1
-of the first byte). In other words the first byte should have the
-bit pattern xxxxxx10 (where x is a randomly generated bit) and the
-remaining 5 bytes are randomly generated See
-[https://en.wikipedia.org/wiki/MAC_address] for more details the
-structure of a MAC address.
-
-
-=item *
-
-Allocate an address from within the space defined by your
-organization's OUI (if you have one) following your organization's
-procedures for doing so.
-
-
-=item *
-
-Allocate an address from within the space defined by Xen's OUI
-(00:16:3e). Taking care not to clash with other users of the
-physical network segment where this VIF will reside.
-
-
-=back
-
-If you have an OUI for your own use then that is the preferred
-strategy. Otherwise in general you should prefer to generate a random
-MAC and set the locally administered bit since this allows for more
-bits of randomness than using the Xen OUI.
-
-
-=head2 bridge
-
-Specifies the name of the network bridge which this VIF should be
-added to. The default is C<xenbr0>. The bridge must be configured using
-your distribution's network configuration tools. See the L<wiki|https://wiki.xenproject.org/wiki/Network_Configuration_Examples_(Xen_4.1%2B)>
-for guidance and examples.
-
-
-=head2 gatewaydev
-
-Specifies the name of the network interface which has an IP and which
-is in the network the VIF should communicate with. This is used in the host
-by the vif-route hotplug script. See L<wiki|https://wiki.xenproject.org/wiki/Vif-route> for guidance and
-examples.
-
-NOTE: netdev is a deprecated alias of this option.
-
-
-=head2 type
-
-This keyword is valid for HVM guests only.
-
-Specifies the type of device to valid values are:
-
-=over
-
-=item *
-
-C<ioemu> (default) -- this device will be provided as an emulate
-device to the guest and also as a paravirtualised device which the
-guest may choose to use instead if it has suitable drivers
-available.
-
-
-=item *
-
-C<vif> -- this device will be provided as a paravirtualised device
-only.
-
-
-=back
-
-
-=head2 model
-
-This keyword is valid for HVM guest devices with C<type=ioemu> only.
-
-Specifies the type device to emulated for this guest. Valid values
-are:
-
-=over
-
-=item *
-
-C<rtl8139> (default) -- Realtek RTL8139
-
-
-=item *
-
-C<e1000> -- Intel E1000
-
-
-=item *
-
-in principle any device supported by your device model
-
-
-=back
-
-
-=head2 vifname
-
-Specifies the backend device name for the virtual device.
-
-If the domain is an HVM domain then the associated emulated (tap)
-device will have a "-emu" suffice added.
-
-The default name for the virtual device is C<vifDOMID.DEVID> where
-C<DOMID> is the guest domain ID and C<DEVID> is the device
-number. Likewise the default tap name is C<vifDOMID.DEVID-emu>.
-
-
-=head2 script
-
-Specifies the hotplug script to run to configure this device (e.g. to
-add it to the relevant bridge). Defaults to
-C<XEN_SCRIPT_DIR/vif-bridge> but can be set to any script. Some example
-scripts are installed in C<XEN_SCRIPT_DIR>.
-
-Note on NetBSD HVM guests will ignore the script option for tap
-(emulated) interfaces and always use
-C<XEN_SCRIPT_DIR/qemu-ifup> to configure the interface in bridged mode.
-
-=head2 ip
-
-Specifies the IP address for the device, the default is not to
-specify an IP address.
-
-What, if any, effect this has depends on the hotplug script which is
-configured. A typically behaviour (exhibited by the example hotplug
-scripts) if set might be to configure firewall rules to allow only the
-specified IP address to be used by the guest (blocking all others).
-
-
-=head2 backend
-
-Specifies the backend domain which this device should attach to. This
-defaults to domain 0. Specifying another domain requires setting up a
-driver domain which is outside the scope of this document.
-
-
-=head2 rate
-
-Specifies the rate at which the outgoing traffic will be limited to.
-The default if this keyword is not specified is unlimited.
-
-The rate may be specified as "/s" or optionally "/s@".
-
-=over
-
-=item *
-
-C<RATE> is in bytes and can accept suffixes:
-
-=over
-
-=item *
-
-GB, MB, KB, B for bytes.
-
-
-=item *
-
-Gb, Mb, Kb, b for bits.
-
-
-=back
-
-
-
-=item *
-
-C<INTERVAL> is in microseconds and can accept suffixes: ms, us, s.
-It determines the frequency at which the vif transmission credit
-is replenished. The default is 50ms.
-
-
-=back
-
-Vif rate limiting is credit-based. It means that for "1MB/s@20ms", the
-available credit will be equivalent of the traffic you would have done
-at "1MB/s" during 20ms. This will results in a credit of 20,000 bytes
-replenished every 20,000 us.
-
-For example:
-
- 'rate=10Mb/s' -- meaning up to 10 megabits every second
- 'rate=250KB/s' -- meaning up to 250 kilobytes every second
- 'rate=1MB/s@20ms' -- meaning 20,000 bytes in every 20 millisecond period
-
-NOTE: The actual underlying limits of rate limiting are dependent
-on the underlying netback implementation.
-
-
-=head2 devid
-
-Specifies the devid manually instead of letting xl choose the lowest index available.
-
-NOTE: This should not be set unless you have a reason to.
-
-=head2 mtu
-
-Specifies the MTU (i.e. the maximum size of an IP payload, exclusing headers). The
-default value is 1500 but, if the VIF is attached to a bridge, it will be set to match
-unless overridden by this parameter.
--- /dev/null
+=encoding utf8
+
+=head1 NAME
+
+xl-network-configuration - XL Network Configuration Syntax
+
+
+=head1 SYNTAX
+
+This document specifies the xl config file format vif configuration
+option. It has the following form:
+
+ vif = [ '<vifspec>', '<vifspec>', ... ]
+
+where each vifspec is in this form:
+
+ [<key>=<value>|<flag>,]
+
+For example:
+
+ 'mac=00:16:3E:74:3d:76,model=rtl8139,bridge=xenbr0'
+ 'mac=00:16:3E:74:34:32'
+ '' # The empty string
+
+These might be specified in the domain config file like this:
+
+ vif = [ 'mac=00:16:3E:74:34:32', 'mac=00:16:3e:5f:48:e4,bridge=xenbr1' ]
+
+More formally, the string is a series of comma-separated keyword/value
+pairs. All keywords are optional.
+
+Each device has a C<DEVID> which is its index within the vif list, starting from 0.
+
+
+=head1 Keywords
+
+
+=head2 mac
+
+If specified then this option specifies the MAC address inside the
+guest of this VIF device. The value is a 48-bit number represented as
+six groups of two hexadecimal digits, separated by colons (:).
+
+The default if this keyword is not specified is to be automatically
+generate a MAC address inside the space assigned to Xen's
+L<Organizationally Unique Identifier|https://en.wikipedia.org/wiki/Organizationally_Unique_Identifier> (00:16:3e).
+
+If you are choosing a MAC address then it is strongly recommend to
+follow one of the following strategies:
+
+=over
+
+=item *
+
+Generate a random sequence of 6 byte, set the locally administered
+bit (bit 2 of the first byte) and clear the multicast bit (bit 1
+of the first byte). In other words the first byte should have the
+bit pattern xxxxxx10 (where x is a randomly generated bit) and the
+remaining 5 bytes are randomly generated See
+[https://en.wikipedia.org/wiki/MAC_address] for more details the
+structure of a MAC address.
+
+
+=item *
+
+Allocate an address from within the space defined by your
+organization's OUI (if you have one) following your organization's
+procedures for doing so.
+
+
+=item *
+
+Allocate an address from within the space defined by Xen's OUI
+(00:16:3e). Taking care not to clash with other users of the
+physical network segment where this VIF will reside.
+
+
+=back
+
+If you have an OUI for your own use then that is the preferred
+strategy. Otherwise in general you should prefer to generate a random
+MAC and set the locally administered bit since this allows for more
+bits of randomness than using the Xen OUI.
+
+
+=head2 bridge
+
+Specifies the name of the network bridge which this VIF should be
+added to. The default is C<xenbr0>. The bridge must be configured using
+your distribution's network configuration tools. See the L<wiki|https://wiki.xenproject.org/wiki/Network_Configuration_Examples_(Xen_4.1%2B)>
+for guidance and examples.
+
+
+=head2 gatewaydev
+
+Specifies the name of the network interface which has an IP and which
+is in the network the VIF should communicate with. This is used in the host
+by the vif-route hotplug script. See L<wiki|https://wiki.xenproject.org/wiki/Vif-route> for guidance and
+examples.
+
+NOTE: netdev is a deprecated alias of this option.
+
+
+=head2 type
+
+This keyword is valid for HVM guests only.
+
+Specifies the type of device to valid values are:
+
+=over
+
+=item *
+
+C<ioemu> (default) -- this device will be provided as an emulate
+device to the guest and also as a paravirtualised device which the
+guest may choose to use instead if it has suitable drivers
+available.
+
+
+=item *
+
+C<vif> -- this device will be provided as a paravirtualised device
+only.
+
+
+=back
+
+
+=head2 model
+
+This keyword is valid for HVM guest devices with C<type=ioemu> only.
+
+Specifies the type device to emulated for this guest. Valid values
+are:
+
+=over
+
+=item *
+
+C<rtl8139> (default) -- Realtek RTL8139
+
+
+=item *
+
+C<e1000> -- Intel E1000
+
+
+=item *
+
+in principle any device supported by your device model
+
+
+=back
+
+
+=head2 vifname
+
+Specifies the backend device name for the virtual device.
+
+If the domain is an HVM domain then the associated emulated (tap)
+device will have a "-emu" suffice added.
+
+The default name for the virtual device is C<vifDOMID.DEVID> where
+C<DOMID> is the guest domain ID and C<DEVID> is the device
+number. Likewise the default tap name is C<vifDOMID.DEVID-emu>.
+
+
+=head2 script
+
+Specifies the hotplug script to run to configure this device (e.g. to
+add it to the relevant bridge). Defaults to
+C<@XEN_SCRIPT_DIR@/vif-bridge> but can be set to any script. Some example
+scripts are installed in C<@XEN_SCRIPT_DIR@>.
+
+Note on NetBSD HVM guests will ignore the script option for tap
+(emulated) interfaces and always use
+C<XEN_SCRIPT_DIR/qemu-ifup> to configure the interface in bridged mode.
+
+=head2 ip
+
+Specifies the IP address for the device, the default is not to
+specify an IP address.
+
+What, if any, effect this has depends on the hotplug script which is
+configured. A typically behaviour (exhibited by the example hotplug
+scripts) if set might be to configure firewall rules to allow only the
+specified IP address to be used by the guest (blocking all others).
+
+
+=head2 backend
+
+Specifies the backend domain which this device should attach to. This
+defaults to domain 0. Specifying another domain requires setting up a
+driver domain which is outside the scope of this document.
+
+
+=head2 rate
+
+Specifies the rate at which the outgoing traffic will be limited to.
+The default if this keyword is not specified is unlimited.
+
+The rate may be specified as "/s" or optionally "/s@".
+
+=over
+
+=item *
+
+C<RATE> is in bytes and can accept suffixes:
+
+=over
+
+=item *
+
+GB, MB, KB, B for bytes.
+
+
+=item *
+
+Gb, Mb, Kb, b for bits.
+
+
+=back
+
+
+
+=item *
+
+C<INTERVAL> is in microseconds and can accept suffixes: ms, us, s.
+It determines the frequency at which the vif transmission credit
+is replenished. The default is 50ms.
+
+
+=back
+
+Vif rate limiting is credit-based. It means that for "1MB/s@20ms", the
+available credit will be equivalent of the traffic you would have done
+at "1MB/s" during 20ms. This will results in a credit of 20,000 bytes
+replenished every 20,000 us.
+
+For example:
+
+ 'rate=10Mb/s' -- meaning up to 10 megabits every second
+ 'rate=250KB/s' -- meaning up to 250 kilobytes every second
+ 'rate=1MB/s@20ms' -- meaning 20,000 bytes in every 20 millisecond period
+
+NOTE: The actual underlying limits of rate limiting are dependent
+on the underlying netback implementation.
+
+
+=head2 devid
+
+Specifies the devid manually instead of letting xl choose the lowest index available.
+
+NOTE: This should not be set unless you have a reason to.
+
+=head2 mtu
+
+Specifies the MTU (i.e. the maximum size of an IP payload, exclusing headers). The
+default value is 1500 but, if the VIF is attached to a bridge, it will be set to match
+unless overridden by this parameter.
=item B<-N> I<netbufscript>
Use <netbufscript> to setup network buffering instead of the
-default script (/etc/xen/scripts/remus-netbuf-setup).
+default script (@XEN_SCRIPT_DIR@/remus-netbuf-setup).
=item B<-F>
+++ /dev/null
-=head1 NAME
-
-@XEN_CONFIG_DIR@/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<domid_policy="xen"|"random">
-
-Determines how domain-id is set when creating a new domain.
-
-If set to "xen" then the hypervisor will allocate new domain-id values on a sequential basis.
-
-If set to "random" then a random domain-id value will be chosen.
-
-Default: "xen"
-
-=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
--- /dev/null
+=head1 NAME
+
+@XEN_CONFIG_DIR@/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<domid_policy="xen"|"random">
+
+Determines how domain-id is set when creating a new domain.
+
+If set to "xen" then the hypervisor will allocate new domain-id values on a sequential basis.
+
+If set to "random" then a random domain-id value will be chosen.
+
+Default: "xen"
+
+=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<@XEN_SCRIPT_DIR@/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<@XEN_SCRIPT_DIR@/remus-netbuf-setup>
+
+=item B<colo.default.proxyscript="PATH">
+
+Configures the default script used by COLO to setup colo-proxy.
+
+Default: C<@XEN_SCRIPT_DIR@/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
"-e Do not wait in the background (on <host>) for the death\n"
" of the domain.\n"
"-N <netbufscript> Use netbufscript to setup network buffering instead of the\n"
- " default script (/etc/xen/scripts/remus-netbuf-setup).\n"
+ " default script (" XEN_SCRIPT_DIR "/remus-netbuf-setup).\n"
"-F Enable unsafe configurations [-b|-n|-d flags]. Use this option\n"
" with caution as failover may not work as intended.\n"
"-b Replicate memory checkpoints to /dev/null (blackhole).\n"
projects / people / sstabellini / xen-unstable.git / .git / commitdiff