The new merged qemu no longer has the ability to spawn a vnc viewer
process in the bowels of the xend/qemu stack. In this patch we
provide support for this use case in a different manner - one more
akin to the mechanism used for `xm console' and `xm create -c'.
We introduce new xm options:
xm create --vncviewer [--vncviewer-autopass]
xm vncviewer [--vncviewer-autopass]
These spawn a VNC viewer, obtaining the relevant information
(including the port number and if you tell it your viewer supports it
the password to use) directly from xenstore.
Like xm console it waits in the foreground for the vnc port to become
available; the timeout case isn't handled as well as it might be - it
just causes the whole program (xm) to die with `Alarm clock' but this
is difficult to deal with given the current structure of the xs Python
lowlevel interface, which doesn't provide a timeout on the call to
wait for a xenstore watch.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Xm did not shut down domains anymore when run in xen-api mode due to a
'None' parameter being passed to xend when looking up a domain. This
fixes the problem.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
This enables the usage of a bootloader, i.e., pygrub, when starting a
domain using xm in Xen-API mode.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
devices without proper FLR capability.
Currently integrated devices without proper FLR capability are not
assignable. This is not nice since actually they may be assignable,
but due to old BIOS the proper FLR capability is not exposed. We can
use the previously-used Dstate transition method to do FLR for them.
This works well and looks few issues are reported AFAIK. Maybe we can
make a black list for the (rare) integrated devices that don't work
with this method.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Certain PCI or PCIe devices needs to be co-assigned. Currently we
require all the related devices be assigned to the same guest. This
can be relaxed to: part of them can be assgined to the same guest, and
after that, the left ones can't be assigned.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
After changeset 18030 and 18064 were checked in, I found some issues
when creating HVM domains with devices assigned.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Move the linux specific labels to osdep where they
belong. Modification on Solaris code ok'd by SUN (Ryan Scott).
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Patch allows keymap to be specified inside vfb description and
allows VM configured keymap setting to override XenD default
Signed-off-by: Pat Campbell <plc@novell.com>
While plugging a xend memory lead (c/s 18030), I introduced a bug in
the case of managed domains. Managed domains continue to exist after
shutdown and thus should not have their associated VMMetrics object
destroyed until deleted.
The bug actually manifested by a new -> start -> shutdown -> delete
sequence of operations. Shutdown destroyed the VMMetrics object and
delete tried to do the same :-):
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
1) If the device is PCIe endpoint and supports PCIe FLR, we use that;
else
2) if the device is PCIe endpoint, and all functions on the
device are assigned to the same guest, we use the immediate parent
bus's Secondary Bus Reset to reset all functions of the device (here,
actually we require all the functions of the device be assigned to the
same guest); else
3) if the device is PCI endpoint and is on a host bus
(e.g. integrated devices), and if the device supports PCI Advanced
Capabilities, we use that for FLR; else
4) we use the Secondary Bus Reset (if the PCI device is behind a
PCI/PCI-X bridge, then all devices behind the uppermost such PCI/PCI-X
bridge above this device must be co-assigned).
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
This allows domains which make buggy assumptions about the maximum
possible MFN to be worked around.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
When a domain is in the process of shutting down there is a small
window when the domain is known to XenD, but it will be unable to form
an SXPR for it due it being in the middle of device hot-unplug. This
causes the 'xm list' command to totally fail with an error like
# xm list
Error: Device 0 not connected
Usage: xm list [options] [Domain, ...]
The 'xm list' command calls into the 'domains' method of
XMLRPCServer.py in XenD. This method just iterates over the list of
domains, fetching the sxpr for each in turn, but with no exception
handling. So if a single domain fails to generate an sxpr, no data is
returned even for other domains which are still functional. This
patch simply makes XenD ignore and skip over domains which throw an
exception, logging the problematic domain.
NB, this problem only hits 'xm list' if it is configured to use the
legay XMLRPC server instead of XenAPI.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Since we only emulate the cirrus VGA video card which is only able to
expose 4MB video memory, we don't need more than that.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
Previous "xend" assumed initial Xenbus state would be "Connected" when
LUN hot-plug starts. However it was not guaranteed in general, and it
may cause some problems.
Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>
The address_bits field will be limited to 8 bits and is now embedded
in the mem_flags member, which additionally contains the node number
(limited to 8 bit).
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
If the guest provides a suspend event channel through xenstore,
xc_save will use it in preference to the old xenstore-based method.
Xend is still informed when the domain has suspended so that it can
perform device migration in parallel with last-round migration.
Signed-off-by: Brendan Cully <brendan@cs.ubc.ca>
If `hda' is used in domU config file and domain-0 has /dev/hda,
creating a domain failed by TypeError:
File "//usr/lib/python/xen/xend/server/blkif.py", line 84, in
getDeviceDetails
(device_path, devid) = blkif.blkdev_name_to_number(dev)
TypeError: unpack non-sequence
Signed-off-by: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
Rework blkdev_name_to_number to allow the tools to attach xvd disks
beyond xvdp.
1. Adds the handling for the /dev/xvd[q-z] and /dev/xvd[a-i][a-z]
extended devices
2. Changes blkdev_name_to_number() to return a tuple of (xenbus,
devnum), and then deals with the resulting fallout.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Enable the labeling of (disk-type) resources with the special label
__INACCESSIBLE__ to prevent unlabeled domains from accessing them.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Currently, when qemu-dm fails, typically its exit status is lost and
xend doesn't notice. In the patch below I use a fifo (named pipe) to
detect qemu-dm's termination and report the exit status to the
logfile, if possible. (If xend has been restarted since the domain
was created, this isn't possible but we can still know that it failed
and report that fact.)
It would be better to have a failure of qemu crash the domain, by
calling the SCHEDOP_shutdown hypercall with SHUTDOWN_crash. However
if you have on_crash=restart and the configuration is broken in some
way that causes qemu-dm to bomb out straight away this causes xend to
spin endlessly restarting the doomed domain. This is a general
problem with on_*=restart and ought to be fixed separately. When it
is fixed, we can safely arrange for domains whose dm has crashed to be
themselves forcibly crashed.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Add pv guest support for the cpuid configuration and checking. That
feature only works for cpuid request which are coming from the guest's
kernel, a process could still call the cpuid directly.
A new policy for pv guest has been created in libxc. dom0 cpuid
emulation is left hardcoded in Xen.
Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
The Xen tools contain a number of Python extensions written in C. The
C API to Python, used by these extensions, is not stable from one
version of Python to the next.
Our build system uses whatever version of Python is the default on the
build system at that time to build these extensions. However, the
actual scripts such as `xm' use #!/usr/bin/env python which uses
whichever version of Python is the default on the deployment system at
the time of invocation.
If for any reason these two versions of Python are not the same (eg,
because the system is built on one computer and executed on another,
or because the system's gains a more recent Python installation
alongside the original which changes the previous default), warnings
and failures occur.
In this patch I arrange for Python scripts to be installed via a
special wrapper around `install', which determines the build-time
Python version and path and then writes that into the #! line at the
point of `make install' (or `make dist'). (It can also be overridden
by setting PYTHON_PATH.)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
In xend/balloon.py, there's only one place where dom0_start_alloc_mb
is used. Move its initialization to right before its usage.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
If device_model is set to '', xend will fail to execute the device
model. If None, xend will detect it and set a sensible qemu-dm path
instead.
Signed-off-by: Yosuke Iwamatsu <y-iwamatsu@ab.jp.nec.com>
Keir Fraser