It does a number of things:
* It implements the standardized options proposed via my RFC for xm
* It restructures the calling of these functions to be function pointers out
of a dictionary, instead of subclasses found through inspection
* It consolidates all help info, making it easier to see that the help
screen looks consistent across commands. (Per command help isn't yet in
this patch just global help)
* It moves object importing into the functions that require them only,
allowing commands like "xm help" to be runable as non root
* It adds command aliasing to provide backwards compatibility with many
commands (i.e. xm balloon)
* It provides more useful error messages is most fail cases
* It implements a short help by default (which takes < 24 screen lines) as
requested by Mark W at OLS
* It attempts to trap more exceptions than before and provide useful errors
based on them (this requires more testing)
This patch makes no changes to any other elements of xen/xm, and works with
all other objects and libraries as is.
Signed-off-by: Sean Dague <sean@dague.net>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
These bits are daemon-only, never come though to userspace. We already
changed them once and broke compilation: better they had never been
referenced.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
xs_watch_stress, reduce cycles in "make check" random test.
2) xs_crashme: corrupt random packets going to xenstored, watch it
crash.
3) Handle second input from before we finished output on first one.
4) Fix bug where one-arg operations are given zero args.
5) Fix bug where SET_PERMS fails after blocking on transaction.
6) Fix memory leak when DIRECTORY op given no argument.
7) Fail on first memory leak, for better testing.
8) Fix missing waiting_for_ack initialization for new connections.
9) Ensure all input and output is handled for domains so we don't stall.
10) Fix overrun bug in xs_count_strings on non-nul-terminated strings.
11) New test for clients which write without waiting for response.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
over to using xenstore for triggers. Dropping the control messages also
fixes the issue with not being able to use xm vcpu-hotplug on dom0.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
of codes for signaling a shutdown request.
Also, we fix the return code for the shutdown notifier, so other
notifiers will get to run ;)
Signed-off-by: Dan Smith <danms@us.ibm.com>
targets into "make -s check" (the GNU standard) which is designed to run
in several seconds or less, with only "<dirname>:" and a seried of "."
for output, and "make fullcheck" which is more verbose and complete, and
runs in minutes.
I plan to submit a patch to plumb these tests in at the top level soon,
with the idea of having a "make -s check" which you can reasonable run
every checkin (time make check << time make), and a "make fullcheck"
which you can run after significant changes.
This patch speeds up testing by making tests one single "xs_test"
script, enhancing xs_test with a simple "expect" command. It also only
runs the "high value" tests under "make check", and leaves the rest for
"make fullcheck".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
still takes one (and just doesn't use it). Noone uses it anyway, so
nothing should break by taking it away.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
xen-unstable.hg but it doesn't add itself to any of the Makefiles but
just as a subdirectory of consoled. There's a README in the directory
that should be read otherwise you won't be able to do anything useful
with it :-)
Right now, we can get pretty far before seeing data corruption.
Previously, we'd see it almost immediately (after ~600 bytes, which is
the max the control channel can hold before filling up).
It's actual general enough that it could be also used to test network
traffic corruption but there are certainly better tools for that.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
does nothing (see ctrl_interface.c:ctrl_chan_write_request()).
The following patch throttles the rate in which consoled writes data to
xcs. With the current values, you get a responsive console but avoid
data corruption in most scenarios.
I'm able to get pretty far in my regression test with this patch. With
higher throttle values I'm able to get even further (but the console
becomes painfully slow).
I implemented proper control channel queuing in xenctld in VM-Tools and
it's pretty nasty stuff. This should prevent corruption for most users
until we can get rid of xcs.
Regards,
Anthony Liguori
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com
1. Converts the shutdown driver and xend to use the store instead of
control messages,
2. Includes Anthony's xenstore notification code, and
3. Changes xend so that sysrq's are no longer sent as "special case"
shutdown messages. Store keys are cheap, so making the sysrq
delivery less obscure is good.
I think I have made all of the appropriate modifications to Xend, but
it is complex, so I may have missed something. Comments are welcome.
Signed-off-by: Dan Smith <danms@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
three patches to fix a problem with Xend starting consoled. consoled
depends on xenstored to be running and xenstored is started on demand in
Xend. The patches change xenstored to manage its own pidfile, and have
xend start actually start up xenstored.
This patch changes the blktap code mapping pages to user space to be
faster and to allow page lookups to foreign mapped pages through linux
to do direct io. An AIO test driver on this achieves comparable
performance to the in-kernel block-backend.
Signed-off-by: andrew.warfield@cl.cam.ac.uk
and changes xm to simply exec /usr/libexec/xen/xc_console.
I've done a pretty good amount of testing and this seems to clear up all
of the Xend console issues in bugzilla.
This is a pretty big change to Xend though with a lot of deleted code so
I'd appreciate if people more familiar with the Xend codebase could look
through it critically.
In addition to the patch, the following files are no longer used:
tools/python/xen/util/console_client.py
tools/python/xen/xend/XendConsole.py
tools/python/xen/xend/server/SrvConsole.py
tools/python/xen/xend/server/SrvConsoleDir.py
tools/python/xen/xend/server/console.py
Regards,
Anthony Liguori
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
There are several people I am aware of interested in writing non-GPL
tools, and this code is trivial, so they'd just end up writing their
own.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2) Fix memory leak in domain free
3) Fix error path in read (reported by aq)
4) Move reading of buffer limit to tty reconnect so that changes in
limit take affect more quickly.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Requires permission check every time event is generated.
Requires generalization of permissions: ask arbitrary number of
parents whether it's OK to tell about node (eg. watching
/dir/subdir/x when /dir is deleted: root permissions will now
determine whether we fire event).
Add test that we don't leak information on whether a file exists
or not.
Signed-off-by: Rusty Russel <rusty@rustcorp.com.au>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
- Add xenbus driver suspend/resume functions
- Change xenbus irq to not be shared
- Translate store mfn in suspend record to pfn and back
- Make tools re-introduce the domain to the store
Signed-off-by: Rusty Russel <rusty@rustcorp.com.au>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
separate daemon. In this patch I've included the daemon and a
front-end. I've also have the console code removed from Xend locally
but I wanted to clarify a few things first before submitting that.
Here's how it works:
1) Daemon sits on control channel (via xcs) waiting for console messages
2) Buffers all console data received
3) Publishes the location of a tty that can be used for reading in
/console/<domid>/tty
4) Reads a value from the store to determine what the limit of console
data should be (/console/<domid>/limit) to prevent DoS attacks
Using it is quite simple, just run consoled and use the xc_console
program to connect to the console. It uses syslog for logging.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
separate daemon. In this patch I've included the daemon and a
front-end. I've also have the console code removed from Xend locally
but I wanted to clarify a few things first before submitting that.
Here's how it works:
1) Daemon sits on control channel (via xcs) waiting for console messages
2) Buffers all console data received
3) Publishes the location of a tty that can be used for reading in
/console/<domid>/tty
4) Reads a value from the store to determine what the limit of console
data should be (/console/<domid>/limit) to prevent DoS attacks
Using it is quite simple, just run consoled and use the xc_console
program to connect to the console. It uses syslog for logging.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
xenstore instead of control messages.
Note: Because there is no way to set a watch on a non-existent key,
this patch includes a workaround to account for the fact that dom0's
store keys are not initialized by the tools before it boots.
Signed-off-by: Dan Smith <danms@us.ibm.com>
and security policy-versioning and data structures in the xen subtree
(ACM):
* the very generic tools directory name "policy" is changed to
"security" and the included "policy_tool" to "secpol_tool"
* the single constant POLICY_INTERFACE_VERSION is replaced
by ACM_INTERFACE_VERSION; the security policy headers are
versioned independently since the policy can be supplied
at boot time instead of through the hypervisor interface
Signed-off-by: Reiner Sailer <sailer@watson.ibm.com>
Signed-off-by: Steven Hand <steven@xensource.com>
to support having reading the boot loader config when you're using a
whole disk (eg, file:/root/disk.img,xvda,w) as opposed to just a
partition.
This reads the partition table in the MBR to find the active partition
and then passes that offset down into the filesystem reading code.
Signed-off-by: Jeremy Katz <katzj@redhat.com>
- Enforce the number of CPUs dom0 will take. See the new variable
"dom0-cpus" in xend-config.sxp (you will want to set this variable to
1 on SMP systems)
- Balloon out dom0 memory when creating domU, if there is not enough
free memory. The lowest level we will balloon out is configured via
the new variable "dom0-min-mem" in xend-config.sxp
I still have a doubt: where to put the code to enforce dom0-cpus. At
the moment I put it into
python/xen/xend/server/SrvDaemon.py, and hopefully that is resonable
enough. Any comment?
Signed-off-by: Nguyen Anh Quynh <aquynh@gmail.com>
When a dom runs on multiple physical cpus, the CPU field doesn't have
much meaning. The suggested fix was to replace the value with '-'.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
