This patch adds a couple of new commands for using the Xen-API
extensions for security policies. Older tools are converted to support
going through the Xen-API for their operations rather than doing the
operations directly in their own code.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
This patch implements extensions for managing security policies in
xend. The XSPolicy and ACMPolicy classes provide the interface for the
Xen-API and implement functionality for setting, updating and
activating of a Xen security policy as well as labeling of virtual
machines and resources such as block devices. Labeling of network
devices will follow.
The acmpolicy class implements a compiler for translating an XML
policy into their binary format and provides functionality for
comparing a current policy against a new one when changing/updating a
policy.
The xspolicyadmin class administers the policy of the system.
Some of the xend-internal code deals with transforming the labeling
information from the S-Expression format into the new Xen-API
format. This is similar to much of the other code that is already
there.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
When failing a migration / save due to the domain owning a PCI device
make sure that we tell the user what went wrong!
Signed-off-by: Mark Williamson <mark.williamson@cl.cam.ac.uk>
This can potentially cause a whole machine crash, which I think has
been seen in the wild. The case in the wild was caused by xendomains
auto-resuming domains on reboot, so it wasn't even operator error.
There's no sane way to migrate or suspend domains with PCI devs,
so I disallow it completely.
Signed-off-by: Mark Williamson <mark.williamson@cl.cam.ac.uk>
This patch adds a duplication definition check for devices.
It checks the following definitions.
- vbd : uname and device name
- vif : mac
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
I'm suggesting this change to make another tiny step towards the
ability to run the tools e.g. out of the build tree (so that multiple
different Xen versions can co-exist without the requirement to
re-install the respective version with each boot).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Has a bad interaction with 12520 in destroyDevice(), where devid is
not an integer as expected.
I'm not sure which of these changesets is really the bogus one, but
this one went in later so it loses. :-)
Signed-off-by: Keir Fraser <keir@xensource.com>
The balloon ioctl value should use a 32-bit value instead of a 16-bit
value to distinguish itself from other ioctls.
Signed-off-by: Ryan Scott <ryan.scott@sun.com>
The keyword 'all' was supported as the 2nd argument of xm vcpu-pin
command since changeset 11619. However, we cannot use the keyword
'all' since changeset 14481.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Prior to this c/s, user was able to specify device name or id, e.g.
xm block-detach dom xvdb
xm block-detach dom 15728
Now, 'xm block-detach dom xvdb' silently fails. xend.log does contain
the following
[2007-06-07 11:39:18 xend.XendDomainInfo 3775] DEBUG
(XendDomainInfo:519) devName=vbd/51712
[2007-06-07 11:39:18 xend.XendDomainInfo 3775] DEBUG
(XendDomainInfo:527) Could not find the device xvdb
This patch restores the previous behavior but retains the bugfix
introduced by c/s 15571.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
When I tested xm mem-max and xm list, I saw the following error
message by xm list. Because xm mem-max always changes
"memory_static_max", I think that the cause of the error message
is it. This patch fixes it.
# xm list --long PVdomain.1 | grep mem
(maxmem 1024)
(memory 1024)
(shadow_memory 0)
# xm mem-max PVdomain.1 512
Error: (22, 'Invalid argument')
Usage: xm mem-max <Domain> <Mem>
Set the maximum amount reservation for a domain.
# xm list --long PVdomain.1 | grep mem
Error: memory_dynamic_max must be less than or equal to
memory_static_max
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Do not destroy domains on shutdown timeout: the administrator needs to
be able to decide what to do if a domain does not shut down.
Signed-off-by: John Levon <john.levon@sun.com>
30 seconds is not a very long time for a busy domain to cleanly
shutdown all its services, which may be arbitrary in
complexity. Increase the timeout to 5 minutes.
Signed-off-by: John Levon <john.levon@sun.com>
