This trivial patch changes VTi guest firmware default name and directory
in xmexample to new directory /usr/lib/xen/boot/guest_firmware.bin. This
aligns with IA32 firmware directory and good to integrate into Fedora
Core.
Signed-off-by Fenghua Yu <fenghua.yu@intel.com>
This simple patch is just to update xmexample.vti
1. Add "vcpus" for supporting SMP VTI.
2. Add serial='pty' for using "xm console" of VTI.
3. Add usb device supporting for VTI.
4. Use cirrus logic accelerated VGA.
Signed-off-by: You Yongkang <yongkang.you@intel.com>
If the bridge is already configure, the default route will point
to a xenbr interface and not an eth interface. Handle this case.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
In the external device migration script I am introducing a subtype
(-subtype <subtype>) from which the script's name is formed. Also all
unparsed parameters are passed to the called script.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
The current code will break if there are multiple scope global routes
since the "ip route list default" command doesn't use "default" as a
filter, and will output multiple devices which breaks the rest of the
script.
Also make the vif/xenbr/eth naming consistent, i.e. if your default
network interface is eth1, you get vif1 and xenbr1.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
contains code that allows to at least detect local migration of a
virtual machine and handles this for the virtual TPM (results in a no-op
for local migr.). If migration of a virtual machine with attached vTPM
to another machine is attempted, XenD will return an error.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
drive image or a TPM, to be migrated to a remote machine. The patch
hooks into the checkpointing (XendCheckpoint.py) code and performs
migration in 4 different steps:
In a 1st step (step = 0 in the code) migration of all devices of a
domain is 'tested', that means their driver implementations (blkif.py,
netif.py, tpmif.py, usbif.py, pciif.py) are queried whether migration is
possible at all. Currently all device representations respond with a
'yes' (=0), although probably a VM mounting a hard drive partition
should respond with a 'no' (-1) already. This first step is a quick
check to see whether devices can be migrated.
The 2nd step is to do whatever can be done before the domain is
suspended. At this point migration of the device could be initiated, if
at all possible.
The 3rd step is to migrate a device after the domain has been suspended,
meaning that it is not scheduled anymore and the VM is 'settled'. All
devices are called again and a good implementation would initiate the
migration in a background process to achieve as much concurrency as
possible.
The 4th step is to synchronize with the 3rd step. At this point the
implementor has to make sure that anything that was initiated in step 3
has completed. Once all steps 4 have been processed, the VM will resume
on the remove machine.
I have implemented hooks for migration of a virtual TPM in
xen/xend/server/tpmif.py. These hooks call a configurable external
migration tool using the os.popen() call with a fixed command line
parameter set. The implementation refuses to migrate a VM attached to a
virtual TPM if no tool has been provided for migration.
All other devices do not currently overload the 'migrate' method defined
in the DevController.py and therefore will just let migration happen.
I have added hooks for error recovery such that whatever part of
migration has been initiated can be rolled back when any of the devices
fail to migrate in one of the steps. The interface (in tpmif.py) to the
external application now uses os.popen() to allow error handling by
reading the application's output.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
* Move .PHONY directives next to targets,
this makes them a lot harder to miss
* Add missing .PHONY directives
* Remove nonexistent .PHONY directives
* Hopefully I didn'T miss anything...
Signed-Off-By: Horms <horms@verge.net.au>
read-only in domain 0, but still fails to be shared with a domU, because
it is mis-identified as being mounted writable. (On SUSE, CDs and DVDs
are auto-mounted not with merely permissions "ro", but
"ro,nosuid,nodev", hence the mis-identification.)
Signed-off-by: Charles Coffing <ccoffing@novell.com>
There are two possible root causes for 515, both of which are only problems in the non-udev hotplug case because udev uses udevsend which already implements the required serialisation.
1) Script concurrency.
2) Kernel reordering hotplug events.
This changeset fixes (1) but not (2). Since (1) is the problem that seems to be happening this is probably OK.
A fix for (2) for the hotplug case might be to add extra serialisation using state changes in the store but this would impact all the drivers and the code and extra complexity would be redundant once everyone had moved to udev. This doesn't seem worthwhile unless we actually start to see (2) happening.
DESTDIR is empty, by preventing readlink from being called in that
case.
Another option would be to use readlink -s, but that has the
undesirable effect of staying silent in situations other than empty
DISTDIR/DESTDIR
Signed-off-by: Aron Griffis <aron@hp.com>
enables you to install SLES-10 as an unmodified guest.
Notice that at this time, vmxassist does not support the graphic bootstrap
loader (gfxboot), so be sure the set "stdvga=1" in your configuration file
to prevent gfxboot from kicking in (or hit SHIFT really fast).
Signed-Off-By: Leendert van Doorn <leendert@watson.ibm.com>
and the hotplug scripts checking whether that domain is still alive. This
triggers the "xenstore-read: couldn't read path /local/domain/107/vm" message
in /var/log/xen-hotplug.log, followed by "Device XYZ is mounted in a guest
domain and so cannot be mounted now".
Closes bug #514.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
script's lock before doing the cleanup, to avoid a race that causes the message
"xenstore-list: could not list path backend/vbd/40" in /var/log/hotplug.log,
with a subsequent refusal to create the domain, after a domain reboot.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
- introduces two basic tests for the virtual TPM (skipped on hardware
where a TPM is not available or vtpm manager has not been started
manually before)
- adapts the Makefiles to make the test cases available
- splits up the hotplug files into two files where the vtpm-common.sh
can be sourced by 'other' scripts as well
- uses echo "$var" to return variables from functions
- gets rid of the 'set +e" work-around
- introduces a script (vtpm-delete) to delete entries from the virtual
TPM directory in /etc/xen/vtpm.db
The xm-tests will skip over the 2nd test on most systems and the patch
has otherwise no effect on existing tests.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
- log() function from xen-hotplug-common.sh -> logging.sh
- locking-related functions from xen-hotplug-common.sh -> locking.sh
- xen-hotplug-common.sh 'sources' both those files now to not loose
these functions (which should make the break-out atomic)
- adapts the Makefile to install locking.sh and logging.sh at the right
place.
I ran the xm-tests over it and no (additional) errors appear due to this
change.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
fail: ip_of() is returning a LIST of IP addresses, one per line.
The vif-scripts attempt to use the list where single addresses ought to
be, with predictable results. This patch changes ip_of() to return
the first address in the list, which seems to be the first one configured.
Signed-off-by: Jim Dykman <dykman@us.ibm.com>
This option is disabled by default, only if we have "pae=1" in config
file, cpuid will return PAE available to VMX guest, and Linux PAE VMX
guest need this. Once the PAE VMX guest support is stable, we will
enable it by default.
Signed-off-by: Xin Li <xin.b.li@intel.com>
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Fix a recently found problem in tpm.c, move the vtpm sysfs
entry to /sys/device/platform/tpm_vtpm and add locking in
the vtpm hotplug script.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
default network device available no matter the name. It can still
be configured if you want a specific network device.
Patch by Bill Nottingham <notting@redhat.com>.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
