xm(1) | Xen | xm(1) |
NAME¶
xm - Xen management user interfaceSYNOPSIS¶
xm subcommand [args]DESCRIPTION¶
The xm program is the main interface for managing Xen guest domains. The program can be used to create, pause, and shutdown domains. It can also be used to list current domains, enable or pin VCPUs, and attach or detach virtual block devices. The basic structure of every xm command is almost always:xm subcommand domain-id
[OPTIONS]
Where subcommand is one of the subcommands listed below, domain-id
is the numeric domain id, or the domain name (which will be internally
translated to domain id), and OPTIONS are subcommand specific options.
There are a few exceptions to this rule in the cases where the subcommand in
question acts on all domains, the entire machine, or directly on the Xen
hypervisor. Those exceptions will be clear for each of those subcommands.
NOTES¶
All xm operations rely upon the Xen control daemon, aka xend. For any xm commands to run, xend must also be running. For this reason you should start xend as a service when your system first boots using Xen. Most xm commands require root privileges to run due to the communications channels used to talk to the hypervisor. Running as non root will return an error. Most xm commands act synchronously, except maybe create, shutdown, mem-set and vcpu-set. The fact that the xm command returned doesn't necessarily mean that the action is complete and you must poll through xm list periodically to detect that the operation completed.DOMAIN SUBCOMMANDS¶
The following subcommands manipulate domains directly. As stated previously, most commands take domain-id as the first parameter.- console domain-id
- Attach to domain domain-id's console. If you've set
up your domains to have a traditional log in console this will look much
like a normal text log in screen.
- create configfile [OPTIONS] [vars]..
- The create subcommand requires a config file and can
optionally take a series of vars that add to or override variables
defined in the config file. See xmdomain.cfg for full details of that file
format, and possible options used in either the configfile or for
vars.
- --help_config
- Print the available configuration variables vars. These variables may be used on the command line or in the configuration file configfile.
- -q, --quiet
- No console output.
- --path
- Search path for configuration scripts. The value of PATH is a colon-separated directory list.
- -f=FILE, --defconfig=FILE
- Use the given Python configuration script. The configuration script is loaded after arguments have been processed. Each command-line option sets a configuration variable named after its long option name, and these variables are placed in the environment of the script before it is loaded. Variables for options that may be repeated have list values. Other variables can be set using name=value on the command line. After the script is loaded, option values that were not set on the command line are replaced by the values set in the script.
- -F=FILE, --config=FILE
- Use the given SXP formated configuration script. SXP is the underlying configuration format used by Xen. SXP configuration scripts can be hand-written or generated from Python configuration scripts, using the -n (dryrun) option to print the configuration. An SXP formatted configuration file may also be generated for a given domain-id by redirecting the output from the the xm list --long domain-id to a file.
- -n, --dryrun
- Dry run - prints the resulting configuration in SXP but does not create the domain.
- -x, --xmldryrun
- XML dry run - prints the resulting configuration in XML but does not create the domain.
- -s, --skipdtd
- Skip DTD checking - skips checks on XML before creating. Experimental. Can decrease create time.
- -p, --paused
- Leave the domain paused after it is created.
- -c, --console_autoconnect
- Attach console to the domain as soon as it has started. This is useful for determining issues with crashing domains.
- with config file
-
xm create Fedora4
- without config file
-
xm create /dev/null ramdisk=initrd.img \ kernel=/boot/vmlinuz-2.6.12.6-xenU \ name=ramdisk vif='' vcpus=1 \ memory=64 root=/dev/ram0
- delete
- Remove a domain from Xend domain management. The xm list command shows the domain names.
- destroy domain-id
- Immediately terminate the domain domain-id. This doesn't give the domain OS any chance to react, and is the equivalent of ripping the power cord out on a physical machine. In most cases you will want to use the shutdown command instead.
- domid domain-name
- Converts a domain name to a domain id using xend's internal mapping.
- domname domain-id
- Converts a domain id to a domain name using xend's internal mapping.
- dump-core [OPTIONS] domain-id [filename]
- Dumps the virtual machine's memory for the specified domain
to the filename specified. The dump file will be written to a
distribution specific directory for dump files. Such as: /var/lib/xen/dump
or /var/xen/dump Defaults to dumping the core without pausing the domain
if no OPTIONS are specified.
- -L, --live
- Dump core without pausing the domain.
- -C, --crash
- Crash domain after dumping core.
- help [--long]
- Displays the short help message (i.e. common commands).
- list [OPTIONS] [domain-id ...]
- Prints information about one or more domains. If no domains
are specified it prints out information about all domains.
- -l, --long
- The output for xm list is not the table view shown below, but instead presents the data in SXP format.
- --label
- Security labels are added to the output of xm list and the lines are sorted by the labels (ignoring case). See the ACCESS CONTROL SUBCOMMAND section of this man page for more information about labels.
- --state=<state>
- Output information for VMs in the specified state.
Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 98 1 r----- 5068.6 Fedora3 164 128 1 r----- 7.6 Fedora4 165 128 1 ------ 0.6 Mandrake2006 166 128 1 -b---- 3.6 Mandrake10.2 167 128 1 ------ 2.5 Suse9.2 168 100 1 ------ 1.8
- r - running
- The domain is currently running on a CPU.
- b - blocked
- The domain is blocked, and not running or runnable. This can be caused because the domain is waiting on IO (a traditional wait state) or has gone to sleep because there was nothing else for it to do.
- p - paused
- The domain has been paused, usually occurring through the administrator running xm pause. When in a paused state the domain will still consume allocated resources like memory, but will not be eligible for scheduling by the Xen hypervisor.
- s - shutdown
- FIXME: Why would you ever see this state?
- c - crashed
- The domain has crashed, which is always a violent ending. Usually this state can only occur if the domain has been configured not to restart on crash. See xmdomain.cfg for more info.
- d - dying
- The domain is in process of dying, but hasn't completely
shutdown or crashed.
The Time column is deceptive. Virtual IO
(network and block devices) used by domains requires coordination by Domain0,
which means that Domain0 is actually charged for much of the time that a
DomainU is doing IO. Use of this time value to determine relative utilizations
by domains is thus very suspect, as a high IO workload may show as less
utilized than a high CPU workload. Consider yourself warned.
- mem-max domain-id mem
- Specify the maximum amount of memory the domain is able to
use. mem is specified in megabytes.
- mem-set domain-id mem
- Set the domain's used memory using the balloon driver.
- migrate domain-id host [OPTIONS]
- Migrate a domain to another host machine. Xend must be
running on other host machine, it must be running the same version of Xen,
it must have the migration TCP port open and accepting connections from
the source host, and there must be sufficient resources for the domain to
run (memory, disk, etc).
- -l, --live
- Use live migration. This will migrate the domain between hosts without shutting down the domain. See the Xen User's Guide for more information.
- -r, --resource Mbs
- Set maximum Mbs allowed for migrating the domain. This ensures that the network link is not saturated with migration traffic while attempting to do other useful work.
- new configfile [OPTIONS] [vars]...
- Adds a domain to Xend domain management.
- --help_config
- Print the available configuration variables vars. These variables may be used on the command line or in the configuration file configfile.
- -q, --quiet
- No console output.
- --path
- Search path for configuration scripts. The value of PATH is a colon-separated directory list.
- -f=FILE, --defconfig=FILE
- Use the given Python configuration script. The configuration script is loaded after arguments have been processed. Each command-line option sets a configuration variable named after its long option name, and these variables are placed in the environment of the script before it is loaded. Variables for options that may be repeated have list values. Other variables can be set using name=value on the command line. After the script is loaded, option values that were not set on the command line are replaced by the values set in the script.
- -F=FILE, --config=FILE
- Use the given SXP formated configuration script. SXP is the underlying configuration format used by Xen. SXP configuration scripts can be hand-written or generated from Python configuration scripts, using the -n (dryrun) option to print the configuration. An SXP formatted configuration file may also be generated for a given domain-id by redirecting the output from the the xm list --long domain-id to a file.
- -n, --dryrun
- Dry run - prints the resulting configuration in SXP but does not create the domain.
- -x, --xmldryrun
- XML dry run - prints the resulting configuration in XML but does not create the domain.
- -s, --skipdtd
- Skip DTD checking - skips checks on XML before creating. Experimental. Can decrease create time.
- -p, --paused
- Leave the domain paused after it is created.
- -c, --console_autoconnect
- Attach console to the domain as soon as it has started. This is useful for determining issues with crashing domains.
- pause domain-id
- Pause a domain. When in a paused state the domain will still consume allocated resources such as memory, but will not be eligible for scheduling by the Xen hypervisor.
- reboot [OPTIONS] domain-id
- Reboot a domain. This acts just as if the domain had the
reboot command run from the console. The command returns as soon as
it has executed the reboot action, which may be significantly before the
domain actually reboots.
- -a, --all
- Reboot all domains.
- -w, --wait
- Wait for reboot to complete before returning. This may take a while, as all services in the domain will have to be shut down cleanly.
- restore state-file
- Build a domain from an xm save state file. See save for more info.
- resume domain-name [OPTIONS]
- Moves a domain out of the suspended state and back into
memory.
- -p, <--paused>
- Moves a domain back into memory but leaves the domain in a paused state. The xm unpause subcommand may then be used to bring it out of the paused state.
- save domain-id state-file
- Saves a running domain to a state file so that it can be
restored later. Once saved, the domain will no longer be running on the
system, thus the memory allocated for the domain will be free for other
domains to use. xm restore restores from this state file.
- shutdown [OPTIONS] domain-id
- Gracefully shuts down a domain. This coordinates with the
domain OS to perform graceful shutdown, so there is no guarantee that it
will succeed, and may take a variable length of time depending on what
services must be shutdown in the domain. The command returns immediately
after signally the domain unless that -w flag is used.
- -a
- Shutdown all domains. Often used when doing a complete shutdown of a Xen system.
- -w
- Wait for the domain to complete shutdown before returning.
- start domain-name [OPTIONS]
- Start a Xend managed domain that was added using the xm
new command.
- -p, --paused
- Do not unpause domain after starting it.
- -c, --console_autoconnect
- Connect to the console after the domain is created.
- suspend domain-name
- Suspend a domain to a state file so that it can be later resumed using the xm resume subcommand. Similar to the xm save subcommand although the state file may not be specified.
- sysrq domain-id letter
- Send a Magic System Request signal to the domain. For more information on available magic sys req operations, see sysrq.txt in your Linux Kernel sources.
- unpause domain-id
- Moves a domain out of the paused state. This will allow a previously paused domain to now be eligible for scheduling by the Xen hypervisor.
- vcpu-set domain-id vcpu-count
- Enables the vcpu-count virtual CPUs for the domain
in question. Like mem-set, this command can only allocate up to the
maximum virtual CPU count configured at boot for the domain.
- vcpu-list [domain-id]
- Lists VCPU information for a specific domain. If no domain is specified, VCPU information for all domains will be provided.
- vcpu-pin domain-id vcpu cpus
- Pins the the VCPU to only run on the specific CPUs. The
keyword all can be used to apply the cpus list to all VCPUs
in the domain.
XEN HOST SUBCOMMANDS¶
- dmesg [-c]
- Reads the Xen message buffer, similar to dmesg on a Linux
system. The buffer contains informational, warning, and error messages
created during Xen's boot process. If you are having problems with Xen,
this is one of the first places to look as part of problem determination.
- -c, --clear
- Clears Xen's message buffer.
- info
- Print information about the Xen host in name : value
format. When reporting a Xen bug, please provide this information as part
of the bug report.
host : talon release : 2.6.12.6-xen0 version : #1 Mon Nov 14 14:26:26 EST 2005 machine : i686 nr_cpus : 2 nr_nodes : 1 cores_per_socket : 1 threads_per_core : 1 cpu_mhz : 696 hw_caps : 0383fbff:00000000:00000000:00000040 total_memory : 767 free_memory : 37 xen_major : 3 xen_minor : 0 xen_extra : -devel xen_caps : xen-3.0-x86_32 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xfc000000 xen_changeset : Mon Nov 14 18:13:38 2005 +0100 7793:090e44133d40 cc_compiler : gcc version 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk) cc_compile_by : sdague cc_compile_domain : (none) cc_compile_date : Mon Nov 14 14:16:48 EST 2005 xend_config_format : 3
- hw_caps
- A vector showing what hardware capabilities are supported by your processor. This is equivalent to, though more cryptic, the flags field in /proc/cpuinfo on a normal Linux machine.
- free_memory
- Available memory (in MB) not allocated to Xen, or any other domains.
- xen_caps
- The Xen version and architecture. Architecture values can be one of: x86_32, x86_32p (i.e. PAE enabled), x86_64, ia64.
- xen_changeset
- The Xen mercurial changeset id. Very useful for determining exactly what version of code your Xen system was built from.
- log
- Print out the xend log. This log file can be found in /var/log/xend.log.
- top
- Executes the xentop command, which provides real time monitoring of domains. Xentop is a curses interface, and reasonably self explanatory.
- uptime
- Prints the current uptime of the domains running.
SCHEDULER SUBCOMMANDS¶
Xen ships with a number of domain schedulers, which can be set at boot time with the sched= parameter on the Xen command line. By default credit is used for scheduling. FIXME: we really need a scheduler expert to write up this section.- sched-credit [ -d domain-id [ -w[ =WEIGHT] | -c[=CAP] ] ]
- Set credit scheduler parameters. The credit scheduler is a
proportional fair share CPU scheduler built from the ground up to be work
conserving on SMP hosts.
- WEIGHT
- A domain with a weight of 512 will get twice as much CPU as a domain with a weight of 256 on a contended host. Legal weights range from 1 to 65535 and the default is 256.
- CAP
- The cap optionally fixes the maximum amount of CPU a domain will be able to consume, even if the host system has idle CPU cycles. The cap is expressed in percentage of one physical CPU: 100 is 1 physical CPU, 50 is half a CPU, 400 is 4 CPUs, etc. The default, 0, means there is no upper cap.
- sched-sedf period slice latency-hint extratime weight
- Set Simple EDF (Earliest Deadline First) scheduler
parameters. This scheduler provides weighted CPU sharing in an intuitive
way and uses realtime-algorithms to ensure time guarantees. For more
information see docs/misc/sedf_scheduler_mini-HOWTO.txt in the Xen
distribution.
- period
- The normal EDF scheduling usage in nanoseconds
- slice
- The normal EDF scheduling usage in nanoseconds
- latency-hint
- Scaled period if domain is doing heavy I/O.
- extratime
- Flag for allowing domain to run in extra time.
- weight
- Another way of setting CPU slice.
xm sched-sedf <dom-id> 20000000 5000000 0 0 0
xm sched-sedf <dom-id> 20000000 0 0 1 0
xm sched-sedf <dom-id> 20000000 5000000 0 1 0
xm sched-sedf <d1> 0 0 0 0 2 xm sched-sedf <d2> 0 0 0 0 3 xm sched-sedf <d3> 0 0 0 0 4 xm sched-sedf <d4> 0 0 0 0 2
xm sched-sedf <d1> 10000000 3000000 0 0 0 xm sched-sedf <d2> 0 0 0 0 2 xm sched-sedf <d3> 0 0 0 0 7 xm sched-sedf <d4> 0 0 0 0 3
VIRTUAL DEVICE COMMANDS¶
Most virtual devices can be added and removed while guests are running. The effect to the guest OS is much the same as any hotplug event.BLOCK DEVICES¶
- block-attach domain-id be-dev fe-dev mode [bedomain-id]
- Create a new virtual block device. This will trigger a
hotplug event for the guest.
- domain-id
- The domain id of the guest domain that the device will be attached to.
- be-dev
- The device in the backend domain (usually domain 0) to be exported. This can be specified as a physical partition (phy:sda7) or as a file mounted as loopback (file://path/to/loop.iso).
- fe-dev
- How the device should be presented to the guest domain. It can be specified as either a symbolic name, such as /dev/hdc, for common devices, or by device id, such as 0x1400 (/dev/hdc device id in hex).
- mode
- The access mode for the device from the guest domain. Supported modes are w (read/write) or r (read-only).
- bedomain-id
- The back end domain hosting the device. This defaults to domain 0.
- Mount an ISO as a Disk
- xm block-attach guestdomain file://path/to/dsl-2.0RC2.iso
/dev/hdc ro
- block-detach domain-id devid [--force]
- Detach a domain's virtual block device. devid may be
the symbolic name or the numeric device id given to the device by domain
0. You will need to run xm block-list to determine that number.
- block-list [-l|--long] domain-id
- List virtual block devices for a domain. The returned output is formatted as a list or as an S-Expression if the --long option was given.
NETWORK DEVICES¶
- network-attach domain-id [script=scriptname] [ ip=ipaddr] [mac=macaddr] [ bridge=bridge-name] [backend= bedomain-id]
- Creates a new network device in the domain specified by domain-id. It takes the following optional options:
- script=scriptname
- Use the specified script name to bring up the network. Defaults to the default setting in xend-config.sxp for vif-script.
- ip=ipaddr
- Passes the specified IP Address to the adapter on creation.
- mac=macaddr
- The MAC address that the domain will see on its Ethernet device. If the device is not specified it will be randomly generated with the 00:16:3e vendor id prefix.
- bridge=bridge-name
- The name of the bridge to attach the vif to, in case you have more than one. This defaults to xenbr0.
- backend=bedomain-id
- The backend domain id. By default this is domain 0.
- network-detach domain-id devid
- Removes the network device from the domain specified by
domain-id. devid is the virtual interface device number
within the domain (i.e. the 3 in vif22.3).
- network-list [-l|--long]> domain-id
- List virtual network interfaces for a domain. The returned output is formatted as a list or as an S-Expression if the --long option was given.
VIRTUAL TPM DEVICES¶
- vtpm-list [-l|--long] domain-id
- Show the virtual TPM device for a domain. The returned output is formatted as a list or as an S-Expression if the --long option was given.
VNET COMMANDS¶
The Virtual Network interfaces for Xen. FIXME: This needs a lot more explanation, or it needs to be ripped out entirely.- vnet-list [-l|--long]
- List vnets.
- vnet-create config
- Create a vnet from a config file.
- vnet-delete vnetid
- Delete a vnet.
ACCESS CONTROL SUBCOMMANDS¶
Access Control in Xen consists of two components: (i) The Access Control Policy (ACP) defines security labels and access rules based on these labels. (ii) The Access Control Module (ACM) makes access control decisions by interpreting the policy when domains require to communicate or to access resources. The Xen access control has sufficient mechanisms in place to enforce the access decisions even against maliciously acting user domains (mandatory access control). Access rights for domains in Xen are determined by the domain security label only and not based on the domain Name or ID. The ACP specifies security labels that can then be assigned to domains and resources. Every domain must be assigned exactly one security label, otherwise access control decisions could become indeterministic. ACPs are distinguished by their name, which is a parameter to most of the subcommands described below. Currently, the ACP specifies two ways to interpret labels: (1) Simple Type Enforcement: Labels are interpreted to decide access of domains to communication means and virtual or physical resources. Communication between domains as well as access to resources are forbidden by default and can only take place if they are explicitly allowed by the security policy. The proper assignment of labels to domains controls the sharing of information (directly through communication or indirectly through shared resources) between domains. This interpretation allows to control the overt (intended) communication channels in Xen. (2) Chinese Wall: Labels are interpreted to decide which domains can co-exist (be run simultaneously) on the same system. This interpretation allows to prevent direct covert (unintended) channels and mitigates risks caused by imperfect core domain isolation (trade-off between security and other system requirements). For a short introduction to covert channels, please refer to http://www.multicians.org/timing-chn.html. The following subcommands help you to manage security policies in Xen and to assign security labels to domains. To enable access control security in Xen, you must compile Xen with ACM support enabled as described under "Configuring Security" below. There, you will find also examples of each subcommand described here.- setpolicy ACM policy
- Makes the given ACM policy available to xend as a
xend-managed policy. The policy is compiled and a mapping (.map) as
well as a binary (.bin) version of the policy is created. The policy is
loaded and the system's bootloader is prepared to boot the system with
this policy the next time it is started.
policy is a dot-separated list of
names. The last part is the file name pre-fix for the policy XML file. The
preceding name parts are translated into the local path pointing to the policy
XML file relative to the global policy root directory
(/etc/xen/acm-security/policies). For example, example.chwall_ste.client_v1
denotes the policy file example/chwall_ste/client_v1-security_policy.xml
relative to the global policy root directory.
- resetpolicy
- Reset the system's policy to the default state where the DEFAULT policy is loaded and enforced. This operation may fail if for example guest VMs are running and and one of them uses a different label than what Domain-0 does. It is best to make sure that no guests are running before issuing this command.
- getpolicy [--dumpxml]
- Displays information about the current xend-managed policy, such as name and type of the policy, the uuid xend has assigned to it on the local system, the version of the XML representation and the status of the policy, such as whether it is currently loaded into Xen or whether the policy is automatically loaded during system boot. With the --dumpxml option, the XML representation of the policy is displayed.
- dumppolicy
- Prints the current security policy state information of Xen.
- labels [policy] [type=dom|res|any]
- Lists all labels of a type (domain, resource, or both) that are defined in the policy. Unless specified, the default policy is the currently enforced access control policy. The default for type is 'dom'. The labels are arranged in alphabetical order.
- addlabel label dom configfile [policy]
- addlabel label mgt domain name [ policy type:policy]
- addlabel label res resource [policy]
- addlabel label vif-idx domain name [ policy type:policy]
- Adds the security label with name label to a domain
configfile (dom), a Xend-managed domain (mgt), to the global
resource label file for the given resource (res), or to a managed
domain's virtual network interface (vif) that is specified by its index.
Unless specified, the default policy is the currently enforced
access control policy. This subcommand also verifies that the
policy definition supports the specified label name.
- rmlabel dom configfile
- rmlabel mgt domain name
- rmlabel res resource
- rmlabel vif-idx domain name
- Works the same as the addlabel command (above), except that this command will remove the label from the domain configfile (dom), a Xend-managed domain (mgt), the global resource label file (res), or a managed domain's network interface (vif).
- getlabel dom configfile
- getlabel mgt domain name
- getlabel res resource
- getlabel vif-idx domain name
- Shows the label for a domain's configuration in the given configfile, a xend-managed domain (mgt), a resource, or a managed domain's network interface (vif).
- resources
- Lists all resources in the global resource label file. Each resource is listed with its associated label and policy name.
- dry-run configfile
- Determines if the specified configfile describes a
domain with a valid security configuration for type enforcement. The test
shows the policy decision made for each resource label against the domain
label as well as the overall decision.
In xen_source_dir/Config.mk set the following
parameter:
Then recompile and install xen and the security tools and then reboot:
XSM_ENABLE ?= y ACM_SECURITY ?= y
cd xen_source_dir; make clean; make install reboot into Xen
To set the system's security policy
enforcement into its default state, the follow command can be issued. Make
sure that no guests are running while doing this.
After this command has successfully completed, the system's DEFAULT policy is
enforced.
xm resetpolicy
This step sets the system's policy and
automatically loads it into Xen for enforcement.
xm setpolicy ACM example.client_v1
This subcommand shows all labels that are
defined and which can be attached to domains.
will print for our example policy:
xm labels example.client_v1 type=dom
dom_BoincClient dom_Fun dom_HomeBanking dom_NetworkDomain dom_StorageDomain dom_SystemManagement
The addlabel subcommand can attach a
security label to a domain configuration file, here a HomeBanking label. The
example policy ensures that this domain does not share information with other
non-homebanking user domains (i.e., domains labeled as dom_Fun or dom_Boinc)
and that it will not run simultaneously with domains labeled as dom_Fun.
We assume that the specified myconfig.xm configuration file actually
instantiates a domain that runs workloads related to home-banking, probably
just a browser environment for online-banking.
The very simple configuration file might now look as printed below. The
addlabel subcommand added the access_control entry at the end of
the file, consisting of a label name and the policy that specifies this label
name:
Security labels must be assigned to domain configurations because these labels
are essential for making access control decisions as early as during the
configuration phase of a newly instantiated domain. Consequently, a
security-enabled Xen hypervisor will only start domains that have a security
label configured and whose security label is consistent with the currently
enforced policy. Otherwise, starting the domain will fail with the error
condition "operation not permitted".
xm addlabel dom_HomeBanking dom myconfig.xm
kernel = "/boot/vmlinuz-2.6.16-xen" ramdisk="/boot/U1_home_banking_ramdisk.img" memory = 164 name = "homebanking" vif = [ '' ] dhcp = "dhcp" access_control = ['policy=example.chwall_ste.client_v1, label=dom_HomeBanking']
The addlabel subcommand supports labeling of
domains that are managed by xend. This includes domains that are currently
running, such as for example Domain-0, or those that are in a dormant state.
Depending on the state of the system, it is possible that the new label is
rejected. An example for a reason for the rejection of the relabeling of a
domain would be if a domain is currently allowed to access its labeled
resources but due to the new label would be prevented from accessing one or
more of them.
This changes the label of Domain-0 to dom_Fun under the condition that this new
label of Domain-0 would not prevent any other domain from accessing its
resources that are provided through Domain-0, such as for example network or
block device access.
xm addlabel dom_Fun mgt Domain-0
The addlabel subcommand can also be
used to attach a security label to a resource. Following the home banking
example from above, we can label a disk resource (e.g., a physical partition
or a file) to make it accessible to the home banking domain. The example
policy provides a resource label, res_LogicalDiskPartition1(hda1), that is
compatible with the HomeBanking domain label.
After labeling this disk resource, it can be attached to the domain by adding a
line to the domain configuration file. The line below attaches this disk to
the domain at boot time.
Alternatively, the resource can be attached after booting the domain by using
the block-attach subcommand.
Note that labeled resources cannot be used when security is turned off. Any
attempt to use labeled resources with security turned off will result in a
failure with a corresponding error message. The solution is to enable security
or, if security is no longer desired, to remove the resource label using the
rmlabel subcommand.
xm addlabel "res_LogicalDiskPartition1(hda1)" res phy:hda6
disk = [ 'phy:hda6,sda2,w' ]
xm block-attach homebanking phy:hda6 sda2 w
xm create myconfig.xm xm list --label Name ID ... Time(s) Label homebanking 23 ... 4.4 dom_HomeBanking Domain-0 0 ... 2658.8 dom_SystemManagement
xm resources phy:hda6 type: ACM policy: example.chwall_ste.client_v1 label: res_LogicalDiskPartition1(hda1) file:/xen/disk_image/disk.img type: ACM policy: example.chwall_ste.client_v1 label: res_LogicalDiskPartition2(hda2)
We distinguish three representations of the
Xen access control policy: the source XML version, its binary counterpart, and
a mapping representation that enables the tools to deterministically translate
back and forth between label names of the XML policy and label identifiers of
the binary policy. All three versions must be kept consistent to achieve
predictable security guarantees.
The XML version is the version that users are supposed to create or change,
either by manually editing the XML file or by using the Xen policy generation
tool ( xensec_gen). After changing the XML file, run the
setpolicy subcommand to ensure that the new policy is available to
xend. Use, for example, the subcommand activatepolicy to activate the
changes during the next system reboot.
The binary version of the policy is derived from the XML policy by tokenizing
the specified labels and is used inside Xen only. It is created with the
setpolicy subcommand. Essentially, the binary version is much more
compact than the XML version and is easier to evaluate during access control
decisions.
The mapping version of the policy is created during the XML-to-binary policy
translation ( setpolicy) and is used by xend and the management tools
to translate between label names used as input to the tools and their binary
identifiers (ssidrefs) used inside Xen.
SEE ALSO¶
xmdomain.cfg(5), xentop(1)AUTHOR¶
Sean Dague <sean at dague dot net> Daniel Stekloff <dsteklof at us dot ibm dot com> Reiner Sailer <sailer at us dot ibm dot com> Stefan Berger <stefanb at us dot ibm dot com>
BUGS¶
2013-01-22 | xen-unstable |