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>
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>
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>
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>
When I changed the scheduler parameters of a domain with
xm sched-credit, the information of xm sched-credit was changed.
But as for the information of xm list, the values of the domain
configuration definition were kept.
And, then I rebooted the domain. The information of xm list was
not changed. But as for the information of xm sched-credit, the
values of the domain configuration definition were returned.
# xm create /xen/PVdomain.1 cpu_cap=150 cpu_weight=512
Using config file "/xen/PVdomain.1".
Started domain PVdomain.1
# xm sched-credit -d PVdomain.1
Name ID Weight Cap
PVdomain.1 1 512 150
# xm sched-credit -d PVdomain.1 -c 75 -w 384
# xm sched-credit -d PVdomain.1
Name ID Weight Cap
PVdomain.1 1 384 75
# xm list --long PVdomain.1 | grep cpu_
(cpu_weight 512)
(cpu_cap 150)
(cpu_time 29.353831745)
# xm reboot PVdomain.1
# xm sched-credit -d PVdomain.1
Name ID Weight Cap
PVdomain.1 2 512 150
# xm list --long PVdomain.1 | grep cpu_
(cpu_weight 512)
(cpu_cap 150)
(cpu_time 5.950247186)
If the scheduler parameters of the domain were changed with
xm sched-credit, I think that xm list should show the current
values about the scheduler parameters.
And, then if the domain is rebooted, I think that the rebooted
domain should keep the preceding values about the scheduler
parameters.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Implement a simpler interface for the hypercalls to ACM. I put the
parameters to all hypercalls into a union. On top of this I have
implemented a shim layer for enabling ACM hypercalls on PPC.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
stage of migration in Xend. The problem was cause by a deletion of the VM domain
ID which is used by testDevicecompleComplete ->deviceIDs->backendRoot() to get
the virtual backend device path. The virtual backend device path is used to
check if a device still exists in xenstore.
Signed-off-by: Yung Giang <yung.giang@gmail.com>
domain builder and in to python code.
This knowledge will be useful to allow us to pre-seed the protocol
field in a VBD entry in xenstore which will allow us to run older
kernels in a 32on64 mixed environment.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
Fix wrong python list assignment for "monitor=1". The old assignment
only works when using qemu-dm.debug in configure file.
Signed-off-by: You YongKang <yongkang.you@intel.com>
Signed-off-by: Zhang Xin <xing.z.zhang@intel.com>
