sysctl.physinfo.nr_cpus. This also avoids miscalculation of
sockets_per_node by Xen where the number of CPUs in the system is
clipped.
From: Elizabeth Kon <eak@us.ibm.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
Tests have been failing because the console for the test ramdisk wasn't using
xvc0 so testcases were not able to interact with it.
Signed-off-by: James Bulpin <james@xensource.com>
- don't reload the policy if it has been loaded
- don't always load the policy in the test suite when the policy is
already loaded
- skip tests 07 and 09 when ACM is not enabled and xm is not using the
Xen-API
- fix a problem when trying to remove an invalid label
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
This adds a couple of test cases exercising the new policy management
functionality to the security tests.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Make the vTPM hotplug script use the UUID of the vTPM instance for
associating it with its instance number rather than the name of the
domain.
Also change the cleanup in the xm test to use the atexit mechanism
rather than explicitly calling a function to clean up.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
1) Sets a minimum of 128MB RAM for an ia64 domU; this limit was set
after experimentation, which seems to indicate it's a reasonable lower
limit (the 32MB limit previously in place did not allow an ia64 domU
to start). If there's any problem with this, I don't mind splitting
the patch and sending it to the ia64 list, but it was small, so I hope
it's okay to include it.
2) xm-test uses ramdisks built with uClibc, which doesn't compile on
ia64. I was able to create a ramdisk by hand, but as it was too
large, the resultant domU crashed after boot. This patch enables the
use of an arbitrarily large ramdisk, so long as it's uncompressed. As
xm-test builds only uncompressed ramdisks, I figured this was
reasonable for that specific application. Suggestions on how to
detect and handle a compressed ramdisk would be welcome.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
This patch changes the XML schema of the ACM policy to require a
version and that every conflict set have a name. Every VM label must
have one Chinese Wall Type and every resource label one Simple Type
Enforcement Type. As a consequence of this some example policies
needed to be changed. Also not offering that many configuration
options for compiling xen anymore to make things simpler.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Scale the memory parameter for domains using the XenAPIDomain to
create a domain. Those domains use the normal configuration where the
memory parameter is given in 'Mb', so it needs to be adapted to
'bytes'.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Remove an uninitialized variable.
For some reason the 'ps aux' command does not see the process anymore
(since some time on the weekend). Need to add 'COLUMNS=n'.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
This patch replaces calls to get_dev_property() by calls to
get_dev_property_by_uuid() in XenAPI.py and fixes the implementation
of get_dev_property_by_uuid.
I am adding a test case to the xapi grouptests to verify the fixes.
There's a FIXME note in the test case which should be looked at.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
- renames the XenManagedDomain.py file to XenAPIDomain.py, since this
name better reflects its functionality/purpose
- adds domain tracking to the XenAPIDomain class so that xend-managed
domains can be deleted in an 'atexit' handler upon test case termination
- adds one basic xapi-related test which is part of the grouptests
'xapi'
- refactors the vtpm-related test using xen-api and adds it to the
grouptest 'xapi'
- adds documentation to the README for how to configure xm and xend to
use XML-RPC or Xen-API for communication
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
in a mode where all created domains a created as xend-managed domains.
This patch also fixes a problem related to calling 'xm domid' on a
currently suspended domain if that domain is a managed domain. In that
case a 'None' is returned by Xend, which I default to '-1'.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
created as managed domains using either a parameter to the
XenTestDomain() constructor or by setting the environment variable
XM_MANAGED_DOMAINS and running the tests with it.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
needs more thought, because people shouldn't need to set up their Xen-API server
to run the non-Xen-API bits of the test, and at the moment, you get
authentication failures on every SKIP.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
similar to the XmTestDomain and XenDomain classes. I have wrapped the
xen-api for VM configuration creation, starting and stopping of VMs and
destruction of the VM configuration in the XenManagedDomain class's
methods. No device-related functions are provided through the class.
The managed domains' UUIDs are tracked and all created VMs are destroyed
upon failure or skipping of the test or by calling
xapi.vm_destroy_all().
I am adding a new grouptest 'xapi' for running xen-api tests.
Only caveat: I am using an empty username and password
(XmTestList/xapi.py) with Xend's authentication deactivated to run these
tests.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
taken, as (significantly) increasing the runtime (without introducing
failures) can be considered a regression. This patch adds a block like:
====
Xm-test timing summary:
Run Started : Fri, 10 Nov 2006 14:53:18 +1100
Run Stopped : Fri, 10 Nov 2006 14:53:20 +1100
====
to the generated report.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>