The ipv6-no-autoconf patch didn't disable IPv6 addrconf completely.
This means that the Xen bridge device still interfered with normal
IPv6 operation by engaging the IPv6 network with a bogus MAC address.
For details please refer to
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200360
The following patch completely disables IPv6 on the Xen bridge device
by temporarily setting the MTU to a value less than the minimum
allowed for IPv6.
Upstream will provide a cleaner way to disable IPv6 addrconf in
future, possibly in the form of a proc sysctl. Of course if the Xen
loopback device is removed it would render this change unnecessary.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Hotplug scripts include certain bash-isms that are not supported under
some distros' default shell (eg. Ubuntu 6.10's use of dash)
Signed-off-by: Alastair Tse <atse@xensource.com>
process begins, and prevents xendomains from attempting to start any
domain that appears there, whether the domain started successfully or
not.
Signed off by: Hugh Brock <hbrock@redhat.com>
contact and authentication details for the Xen-API server.
The default behaviour is still to use the existing legacy XML-RPC server.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
to use PAM, or to be turned off entirely, on a listener by listener basis.
Listen on a different unix domain socket for the Xen-API server, so that it
can co-exist with the others.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
code from the relocation protocol handling and some plumbing. Add a new
configuration entry for the Xen-API server, including use of this mechanism.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Also simplify the HVM builder interface by doing more work in
the python wrapper, and fix mapping of shared_info page after the
change to map foreign pages by GMFN rather than MFN.
Signed-off-by: Keir Fraser <keir@xensource.com>
Now users will see the following error:
[root@bebop ~]# xm create -c 128
Using config file "/etc/xen/128".
Error: Device 51713 (tap) could not be connected.
/tmp/128.img does not exist
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
external-device-migrate script in its handling of parameters.
Patch from Roland Illig <roland.illig@gmx.de>.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
and extra code in hvm_vcpu_initialise(). Remove 'apic' config
option -- HVM CPUs will always have an APIC (which should be
set up in virtual wire mode for backward compatibility, just as
in a real system).
Signed-off-by: Keir Fraser <keir@xensource.com>
This prevents an error from being logged. Use the wrapped command for
reading from the xenstore instead of the native one.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
that the VNC server from qemu listens on.
Defaults to only listen on 127.0.0.1
The old behaviour (listen on all interfaces) can be restored, by
- changing the system-wide default in /etc/xen/xend-config.sxp by adding:
(vnc-listen '0.0.0.0')
- changing individual domain config files by adding:
vnclisten="0.0.0.0"
Also allows specifying the hostname associated with an interface to limit
to that interface.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch makes blktap Do The Right Thing(TM). It allows udev to
create the /dev/xen/blktap[0-9] devices.
It creates a sysfs class called "xen". This part may later be placed
someplace else, but currently blktap is the only user so it is placed in
the blktap code.
When blktap is initialized, a blktap0 sysfs class device is made. The
other devices blktapX (X > 0) are made when the BLKTAP_IOCTL_NEWINTF
ioctl is called. This way we don't flood the sysfs and /dev/xen with
unnecessary devices.
I added a rule in the xen-backend.rules to allow for udev to create the
blktap devices.
With this, we can really remove the code to search and create the
/dev/xen/blktap[0-9]*, but I'll leave it in for now. With the use of
udev, we really should remove that code as well as the code for creating
the evtchn device. udev works for both of these now. But that removal
will have to be in another patch.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
local migration since this does not seem to work correctly (see tests in
xm test suite). If no vTPM has been attached, the local migration
proceeds as usual.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
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>
