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>
RHEL4U4 PAE SMP guest currently crashes, and we found changeset 15214
introduced it. This patch fixes it.
Signed-off-by: Xin Li <xin.b.li@intel.com>
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
FC5's gcc 4.1.0 can't make some files in tools/ due to its stronger
type checking.
From: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
The new version of qemu uses 5900 instead of 0 as the port.
There is no need to offset it by 5900 when writing out the
console/vnc-port entry.
Signed-off-by: Ben Guthro <bguthro@virtualiron.com>
Use atomic updates to read/write usb controller data.
This can be done because:
a) word copies on x86 are atomic
b) The USB spec requires word alignment
This will need to be enhanced once USB 1.2 is supported.
Signed-off-by: Steve Ofsthun <sofsthun@virtualiron.com>
Update to copy 'longword'-sized atoms.
Signed-off-by: Keir Fraser <keir@xensource.com>
or uuid via xend logs, less unique than pids to prevent excessive
number of log files hanging around, yet not immediately reused (unlike
e.g., after domain crash or reboot) where previous log file is
immediately overwritten. Not using domain names in logs avoids and
chance of unprintable charcatres becoming embedded in filenames.
Signed-off-by: Keir Fraser <keir@xensource.com>
Change the logfile name generated by qemu-dm to use the pattern
qemu-dm-[NAME].log instead of qemu-dm-[PID].log. This makes it
easier for the adminsitrator to figure out which log corresponds to
which guest (particularly after a crash where you no long know what
PID the qemu-dm process for your guest had). It also prevents the
number of log files from growing unbounded.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* The --log command line argument takes one of 4 values
- none - no logging (the default)
- hv - log all hypervisor messages
- guest - log all guest messages
- both - log all guest & hypervisor messages
* The --log-dir command line argument takes a path to specify where
to store logfiles. If omitted it defaults to /var/log/xen/console
* The hypervisor logfile is $LOGDIR/hypervisor.log
* The guest logfile is $LOGDIR/guest-[NAME].log
* If receiving a SIGHUP it will close & re-open all log files to
enable logrotate to do its magic
* Fixes the permissions of /var/run/xenconsoled.pid
* Adds a --pid-file command line argument to override the default
location of pid file (this is not really related to logging, but
since I was in that code...)
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The only non-obvious change here is in tools/xenfb/Makefile. This now picks up
the headers it requires via the copy in tools/libxc.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
Our @us.ibm.com emails cannot forward to us; we do not have access to
them when not interning at IBM. People have attempted to reach us via
those addresses and failed; occasionally they've Googled for a current
address, which made us realize the problem. Change each email to a
more permanent address, so people can reach us in the future. Change
bug reporting addresses to a xen mailing list rather than an
individual.
Signed-off-by: Josh Triplett <josh@kernel.org>
c/s 15021 updated Qemu to 0.90. In the new Qemu's ide.c, asynchronous
IO (AIO) is used to replace the previous DMA thread; here when an AIO
request is completed, dom0 sends a signal SIGUSR2 to Qemu (see
block-raw.c: qemu_aio_init(),raw_aio_setup()), then the signal
interrupts the select() in main_loop_wait() at once, next,
qemu_aio_poll() is called to reap a completed AIO request.
However, in certain Linux distributions (i.e., x86_64 RHEL 4u4), if
Qemu is spawned by the python script image.py of Control Panel, the
SIGUSR2 of Qemu is blocked by default due to some reasons (i.e. it
seems Python 2.3.4 has this issue; 2.4.2 is ok); so in most cases the
select() in main_loop_wait() can only time out in 10ms, then the
qemu_aio_poll() is called - this results in a very slow disk IO
speed...
This patch ensures aio_sig_num is unblocked when the AIO is used in
Qemu 0.90.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.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>
xenstored is incorrectly accounting domain nodes when transactions
fail. Store pending count changes in the transaction structure, and
apply at transaction completion, instead of directly applying the
changes.
Signed-off-by: Max Zhen <max.zhen@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>
Instead of violently destroying a domain that is not responding to a
shutdown request, rename the domain to indicate the problem and leave
it alone; this allows the admin to make corrective actions (which may
or may not include destroying the domain).
Signed-off-by: John Levon <john.levon@sun.com>
The Domain ID is currently expected to fit in 3 digits.
When doing extensive testing on SAVE/RESTORE I can easily get ID's
into the 4-digit range, which makes some of the formatting to get out
of sync. Extend the width to 5 digits (and change some %-ns to %ns, as
the ID for example is right justified, %-ns is left-justified, which
didn't look too good).
Signed-off-by: Mats Petersson <mats.petersson@amd.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>
As there is a (small) chance that vl.c:tap_open() fails (due to some
sort of race-condition in the Linux kernel, which is noted as a bug in
the source .../net/core/dev.c), we should attempt it again a couple of
times if it doesn't succeed on the first attempt. I think three times
in total is sufficient to avoid the problem.
If tap_open() fails, qemu-dm will exit, which means that the domain
dies - which is not such a good thing when attempting to restore a saved
domain [of course, it would be even worse if it started, but didn't
have networking - because there may not be a way to shut it down
cleanly without network].
Signed-off-by: Mats Petersson <mats.petersson@amd.com>
The function XendDomainInfo:_releaseDevices() is called during the
save/destroy phase of a domain. It made some attempt to clean up the
devices, but wasn't complete, leaving dangling devices in the
xenstore. Not a big problem with normal use of Xen, but a buildup over
a large number of save/destroy instances, it would make the xenstore
database grow quite large, which in turn meant swap-thrashing in Dom0.
This patch makes use of the destroyDevices() function in
XendDomainInfo. This function needed some re-writing to make it work
correctly - I think it had some old code (not sure how old, as xm
annotate says that it's changeset 12071, but that, I think, is when it
was split out from XendDomain.py, rather than when it was created).
I have tested this over a few hundred save/restore cycles [two domains
constantly saved/restored with a short sleep to let them process some
work] combined with a loop of "xenstore-ls|wc". The output of the
latter is pretty much constant (it obviously varies a bit depending on
when in the save/restore cycle it hits). Previously, it would increase
by some 10 lines or so per save/restore cycle.
Signed-off-by: Mats Petersson <mats.petersson@amd.com>
When compiling the various blktap drivers with warnings cranked up, I
get errors that return values are not checked.
Signed-off-by: Charles Coffing <ccoffing@novell.com>
If creating an unmanaged guest (eg xm create), if device hotplug fails
during the startup of the guest, then the guest will be torn down
again. If creating and starting a managed guest (eg xm new && xm
start), then if device hotplug fails, the still born guest gets left
in 'paused' state. This confuses users no end, who go an unpause and
then get all upset when it shortly crashes (due to lack of disk or
network devices).
The attached patch fixes XenDomain.py's domain_start() method so that
if waitForDevices() fails, then the entire domain is torn down. This
is the same approach used in xm create.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
