The save failure cleanup introduced in 13543:207523704fb1 is
incorrect: if we didn't get as far as actually suspending the domain,
then the guest domain will not be expecting the devices to be removed
(seen on both Linux and Solaris, which don't expect a 'Closing' state
when they hold the device open). Only re-jig devices if we definitely
shut the domain down.
Signed-off-by: John Levon <john.levon@sun.com>
This patch provides the tools support for direct kernel boot of
HVM guests. Currently the config files in /etc/xen support the
args 'kernel', 'ramdisk' and 'extra'. For PV guests these have
the obvious meaning.
Unfortunately HVM guest configs hijacked the 'kernel' parameter
and use it to refer to the path of the HVM firmware. So, this
patch adds a new config file parameter called 'loader' which is
used to refer to the HVM firmware instead.
The conventions for loading the initrd image say that it should
live at the end of memory. This requires QEMU to know the size
of the guest's initial RAM allocation, so image.py is changed
to pass the '-m' flag to QEMU.
The HVMImageHandler class in image.py is changed so that if the
'kernel', 'ramdisk' or 'extra' params were given in the config
these are passed to QEMU with the '-kernel', '-initrd' and
'-append' flags respectively.
Finally, the 'loader' param is used as the arg to 'xc_hvm_build'
instead of the old 'kernel' param.
For the sake of compatability with old HVM guest config files,
if the config file has a 'kernel' param whose path matches that
of the HVM firmware, then we automatically convert this 'kernel'
param into the 'loader' param. This ensures existing HVM guests
work without changes required.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
xc.domain_destroy_hook() is called twice when we execute
xm shutdown/reboot command to an HVM domain without PV drivers.
The first calling is from shutdown() in XendDomainInfo.py.
The second calling is from destroyDomain() in XendDomainInfo.py.
The first calling is not necessary, so this patch removes it.
A discussion about this patch is as follows.
http://lists.xensource.com/archives/html/xen-ia64-devel/2008-01/msg00232.html
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Add domain name to a migrateDevice call, so the helper script
(external-device-migrate example) does not fail at step 0
(MIGRATION_TEST).
Signed-off-by: Pascal Bouchareine <pascal@gandi.net>
When setting e.g. 'on_crash=rename-restart' option in domain config
and crashing guest OS running in the domain, the new domain is
restarted with same name as renamed domain.
jfehlig4: # xm li
Name ID Mem VCPUs State Time(s)
Domain-0 0 1233 4 r----- 937.9
Domain-e64b12a0-0493-44d7-afde-55c776513426 21 384 1 ---c- 14.3
Domain-e64b12a0-0493-44d7-afde-55c776513426 22 384 1 r----- 7.3
This patch copies the domain info prior to setting new name and uuid
in the crashed domain info and uses the copied domain info to
construct the restarted domain.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
The crashed power state is necessary to allow both core-dumping a
crashed but preserved VM and renaming/restarting a crashed VM.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
Stubdomains (and probably other domain disagregation elements too)
need to be able to tinker with another domain. This adds
XS_SET_TARGET so that XenStore allows domains to have permissions on
files on which the "target" has permissions. This also adds
xs_set_target, called by the domain builder when the 'target' option
is used in the configuration.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
Stubdomains (and probably other domain disagregation elements too)
need to be able to tinker with another domain. This adds IS_PRIV_FOR
that extends IS_PRIV by allowing domains to have privileges over a
given "target" domain. XEN_DOMCTL_set_target permits to set this
"target". A new 'target' configuration option makes the domain builder
use it.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
I tested xm block-attach command with a wrong
parameter(file:). Naturally a command error occurred. Then I retested
xm block-attach command with a correct parameter(phy:). But a command
error occurred again. The second command error occurred because Xend
did not remove device information from self.info when the first
command error occurred.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
In various places in documentation and code, IP addresses are provided
as examples, defaults, or dummy configuration. In general the
specific IP addresses used in Xen are not always appropriate. (For
example, 1.2.3.4 is used in a few places!)
The following addresses should be used:
* For examples and documentation, 192.0.2.0/24. (See RFC3330.)
* For defaults for private networks, a random network from RFC1918.
I have randomly selected 172.30.206.0/24 for this purpose and
documented this in at the only registry I know of,
www.ucam.org/cam-grin. This network should henceforth be used for
default configurations of local bridges, test networks, etc. in
Xen tools.
The following addresses should NOT be used:
* 10.0.*.*, 10.1.*.*, 192.168.0.*, 192.168.1.*, etc. Using these
addresses gives greatly increased likelihood of collision, as
ignorant network administrators and reckless middlebox vendors
often pick networks from the bottom of 10/8 and 192.168/16.
* 169.254.*.*. These are reserved for zeroconf (ad-hoc networking)
and should not be used for Xen private networks, bridges, etc.,
etc. Use of these addresses by Xen scripts causes trouble on hosts
(eg laptops) which find themselves in ad-hoc networking
environments. I think this is not hypothetical (!) since at least
one Linux distribution have specific code to detect this case and
cause Xen startup to fail iff the host already has an external
zeroconf address.
* 1.2.3.4. WTF !?
I have also used 127.0.255.255 in one place where apparently a dummy
address is needed (some Linux kernels won't accept a lack of an NFS
server address). If 127.0.255.255 is mistakenly used it is unlikely
to do any damage to real traffic even if it does escape into the
network at large.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
This fixes two problems related to the SR class:
- get_PBDs() was not implemented
- get_physical_size did not work
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
xend can get into a situation where two processes are attempting to
interact with the xenstore socket, with disastrous results. Fix the
two bad users of xstransact, add a big warning, and fix the destructor
so future mistakes will be detected earlier.
Signed-off-by: John Levon <john.levon@sun.com>
Xend doesn't correctly work after restart, when there is a domU which
owns a pci device (driver domain). This patch fixes the problem.
Signed-off-by: Yosuke Iwamatsu <y-iwamatsu@ab.jp.nec.com>
With current XenD 3.0.4 or later try the following:
brctl addbr demo
ifconfig demo up
/etc/init.d/xend start
/etc/init.d/xend stop
ifconfig demo down
brctl delbr demo
Now, start XenD again....
/etc/init.d/xend start
And watch in horror as it re-creates your 'demo' bridge.
The problem is that the 'XendNetwork' class does not distinguish
between bridge devices that it is managing (ie those created via
XenAPI) and those which it does not manage (ie those created by OS
distro init scripts, or by apps like libvirt).
While initially I thought I could just make XenD ignore
externally-managed bridges completely, it seems to needs to know about
them otherwise it can't hook up guest VIFs to them correctly. So the
attached patch adds a 'managed' flag to the XendNetwork
class. Externally managed bridges have this set to False. At startup
XenD will now only re-create bridge devices which have the 'managed'
flag set to 'True' - ie those created via XenAPI.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Instead of starting a thread per script, run a single thread and send
orders to it. This serializes the execution of the scripts.
Signed-off-by: Stefan Berger <stefanB@us.ibm.com>
I am implementing some missing interface functions in the XSM dummy
module. Also deactivating some debugging output.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
When unmanaged domains with on_xend_stop="suspend" exist, managed
domains are not suspended by xend stop command. The processing of
cleanup_domains() is aborted by exception. This patch keeps suspending
managed domains even if unmanaged domains exist.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Distutils won't install xsview unless it has an __init__.py. This
patch adds an empty one, which is all that is required.
Signed-off-by: Mark Williamson <mark.williamson@cl.cam.ac.uk>
This makes no difference to the visible behaviour of "xm top" but
avoids the whole of xm from quitting if you're in "xm shell". This
provides the more intuitive behaviour of returning to the xm shell
interface after leaving xm top.
Signed-off-by: Mark Williamson <mark.williamson@cl.cam.ac.uk>
Some relics in the control tools still refer to the USB paravirt
driver. Remove this as it's dead code and is in the history for
anyone really interested. The Qemu device model has its own USB
configuration, which should still work.
Signed-off-by: Mark Williamson <mark.williamson@cl.cam.ac.uk>
This patch extends the Xen-API and the legacy XML-RPC interface with a
function to reset the policy on the system (through an update with the
default policy). I adapted the code in 'xm resetpolicy' to use this
now.
This patch also extends libxen and the documentation to reflect the
new function.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
We can give multiple domains to the following commands.
But, the help messages of the commands are explained to be able
to give a single domain.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Recover the system if the XML representation of the currently loaded
policy is missing. Force the installation of the DEFAULT policy.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
This patch moves the directory of files where xend is writing policies
and resource labels into to /var/lib/xend/security/policies.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
This patch implements a (non Xen-API) legacy XML-RPC interface for the
ACM commands and funnels the calls into code introduced by the Xen-API
support for ACM security management. Since some of the functionality
has changed, also the xm applications have changed. In particular the
following old commands have been removed along with some tools the
have become obsolete now:
- loadpolicy (included in: setpolicy)
- makepolicy (included in: setpolicy)
- cfgbootpolicy (included in: setpolicy)
and the following commands been introduced:
- setpolicy
- getpolicy
- resetpolicy
All tools have been adapted to work in Xen-API and legacy XML-RPC
mode. Both modes support the same functionality.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Although XenAPI c-bindings support this operation on Network class,
there is no implementation in xend. This patch provides one.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
This makes use of the domain config option guest_os_type for
ia64 and removes the backing for the previous ACPI based
mechanism used previously. A user wanting optimal performance
for a specific type of OS guest running in an HVM domain should
make use of this new option. See updated xmexmaple.vti for
available options. All supported OSes should always work using
the default option or leaving the option unspecified. Originally
based on patch from Zhang Xin.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Keir Fraser
Alex Williamson