be under /var/log/xen instead of under /var/log directly. This has
the advantage of cleaning things up a little and also can make it
easier to restrict the permissions needed by xend.
Signed-off-by: Jeremy Katz <katzj@redhat.com>
scripts -- apparently it is not needed (reported by
Tuan Van <lang.thang@gmail.com>). See bugzilla issue #741
for more details.
Signed-off-by: Keir Fraser <keir@xensource.com>
I have experienced that the vif-route script does not work as expected
when deleting a virtual interface (Redhat FC5). Both of the commands
"ifdown" and "ip route" cause an early vif-route script exit and
therefore will cause skipping of the later script commands (such as
cleaning up iptables entries for the default 'antispoof'). The
vif-route
script creates the following syslog error entry:
"/etc/xen/scripts/vif-route failed; error detected."
It appears that both of the problematic commands are actually
redundant
when destroying domains:
1. the interface is already gone (I assume because the domain frontend
is gone already) --> ifdown does not do anything
2. the route is gone as well since the interface has disappeared -->
ip
route del does not do anything
Executing those redundant commands with "do_without_error" ensures
that
the script completes and cleans up iptables rules. The attached
RFC-patch only masks those commands when bringing down an interface,
so
that domain creation continues to fail in case of vif setup problems
(intended behavior).
Having the iptables cleanup called correctly by vif-route is important
to keep the iptables rule-set clean, otherwise antispoof rules
accumulate with every vif creation.
Signed-off by: Reiner Sailer <sailer@us.ibm.com>
This makes the script more idempotent if run twice (e.g. from hotplug and udev), since the second time the device will be taken down and not brought up again, leaving the host without networking.
Signed-off-by: Anil Madhavapeddy <anil@xensource.com>
The rombios supports trying to boot from more than one device and then
falling back. Set 'boot=dc' in your config file to try booting first
from the CD and then the hard drive.
Based on a patch from: Jeremy Katz <katzj@redhat.com>
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
1) xend can't start due to xend-config.sxp
2) qemu dm option vncunused should be effective only
when vnc is turned on.
Signed-off-by: Xin Li <xin.b.li@intel.com>
If the port used for the requested display number is in use, try
additional ports until a free port is found.
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
1. xend-pci-quirks.sxp:
Specifies which PCI device(s) may write to a set of PCI configuration
space registers. A quirky PCI device is identified by its vendor ID,
device ID, subvendor ID, and subdevice ID. If a matching entry is
found, the corresponding fields will be sent to the PCI bus manager.
Fields are composed of a register, size, and mask -- although the mask
field is currently unused.
The included policy file is for a range of tg3 devices, which is the
only type of quirky device I know about. Users with other quirky
devices are invited to either add entries to this policy file or add
an entry in the permissive file, described next. In either case, send an
email to the xen-devel list to make the device known.
2. xend-pci-permissive.sxp
Lists PCI devices that pciback should not prevent from writing to
their configuration space. This can be necessary if, for example, a new
Tigon3 devices is released with different PCI vendor/device values
such that no entry in xend-pci-quirks.sxp is triggered.
Signed-off-by: Chris Bookholt <hap10@tycho.ncsc.mil>
- add vncviewer option to qemu-dm to spawn a vncviewer process.
- add the `vncconsole' config parameter which enables qemu-dm's vncviewer
option.
Based on a patch from: Don Dugger <donald.d.dugger@intel.com>
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
Also add vncdisplay= option which allows setting the display number
instead of using the default display number (= domid).
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
Remove the ne2000 option, the network device type can now be selected
on a per-device basis by adding a model= property to the device's entry
in the vif list.
Signed-off-by: Christian Limpach <Christian.Limpach@xensource.com>
vtpm-common.sh
script. The newly created function 'vtpm_add_and_activate' also
assigns
the instance number to the xenstore entry to activate the backend.
Renaming of isLocalAddress function to vtpm_isLocalAddress.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
works provided that the hotplug scripts deliver the "suspend" before
the "resume," but this is not always true.
Signed-off-by: Vinnie Scarlata <vincent.r.scarlata@intel.com>
enable a virtual TPM to save its state between reboots of the virtual
TPM implementation.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Signed-off-by: Vincent Scarlata <vincent.r.scarlata@intel.com>
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>
