correct log file.
At the same time, this patch renames the logfile to be
'qemu-dm-{NAME}.log' instead of qemu-dm-{ID}.log. This makes it
easier to track/find the QEMU logfile associated with a VM. It will
also save 1 backup qemu-dm-{NAME}.log.1 so if a domain crashes &
restart, you don't loose/overwrite the logfile immediately.
Finally it changes the QEMU monitor prompt back to '(qemu)' instead of
'(HVMXen)' because automated tools /scripts interacting with QEMU's
monitor need a consistent prompt to look for & changing it for Xen
serves no useful purpose.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Saved images contain rtc_timeoffset as a string value, resulting in a
TypeError exception when calling xc.domain_set_time_offset() on
restore. Cast rtc_timeoffset to int before calling
xc.domain_set_time_offset().
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
This patch adds support for the qcow2 image format to blktap. It
consists mostly of qemu code, adapted to the blktap interfaces.
Snapshots and compressed images are supported.
The qcow2 driver may be used by either specifying tap:qcow2 or by
using tap:qcow which will detect that you have a version 2 image and
will call the qcow2 driver.
Signed-off-by: Kevin Wolf <kwolf@suse.de>
** Currently only 2 virtual hotplug pci slots(6~7) are created so more
than 2 vtd dev can't be hotplugged, but we can easily extend it in
future.
Three new commands are added:
"xm pci-list domid" show the current assigned vtd device, like:
VSlt domain bus slot func
0x6 0x0 0x02 0x00 0x0
"xm pci-detach" hot remove the specified vtd device by the virtual
slot, like:
xm pci-detach EdwinHVMDomainVtd 6
"xm pci-attach DomainID dom bus dev func [vslot]" hot add a new vtd
device in the vslot. If no vslot specified, a free slot will be picked
up. e.g. to insert '0000:03:00.0':
xm pci-attach EdwinHVMDomainVtd 0 3 0 0
** guest pci hotplug
linux: pls. use 2.6.X and enable ACPI PCI hotplug ( Bus options=> PCI
hotplug => ACPI PCI hotplug driver )
windows: 2000/xp/2003/vista are all okay
Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Make qemu unblock SIGHUP and make sure the default handler is in
place. Have the domain killer send SIGHUP to the device-model script,
allow the script 10s to clean up, and if still not dead, send
SIGKILL.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
Currently, a wrong value of maximum memory size is checked by
_safe_set_memory() and _memory_sanity_check().
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
A new platform variable 'hpet' is added, which defaults to 0 for new
guests (that is, hpet disabled). Default is off (no hpet) because
hpet is currently less accurate in keeping time than PIT (because no
timer_mode adjustments).
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
via the 'kernel' config option:
1. Look for any string containing 'hvmloader'.
2. The 'kernel' option must be scrubbed to avoid taking
PV-kernel-loading paths during later guest setup.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
When setting
vfb = [ 'type=sdl' ]
in a domain config file, qemu seems to be still using vnc. Make it use
sdl as expected.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
Xen-API already specifies these actions for the 'on_crash' domain exit
event. This patch makes them available for use in traditional domU
config files and through the xm tool as well.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
When I rebooted a domain by xm reboot command with wait option,
I saw the following message. But, rebooting the domain succeeded.
Domain vm1 destroyed for failed in rebooting
The cause why the message was shown is the domain is destroyed
temporarily by processing of xm reboot command. The domain
information is not gotten from Xend by server.xend.domains()
function till recreating the domain is completed.
This patch fixes processing of xm reboot command in Xm side.
It waits just a bit till recreating the domain is completed,
then it measures the success or failure of the reboot of the
domain.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
When guest domains are restarted, previous values of /vm/uuid/xend/*
in xenstore are lost. (e.g. previous_restart_time,
last_shutdown_reason). This patch restores them to restarting domains.
And we should update /vm/uuid/xend/restart_count of restarting
domains, not previous domains.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
The stub domain device model needs to trap the termination signal so
as to actually destroy the stub domain. SIGKILL can't be trapped,
SIGTERM is caught by SDL and so may be unnoticed. SIGHUP can be
trapped and is not caught by SDL (and by default causes a process
termination without core).
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
Continue to SIGKILL qemu-dm so that 'xm destroy' should always work
rather than hang if qemu-dm is in a bad state.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
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>
Keir Fraser