is specified, from guest-2, guest-3 etc. Have the DHCP server send the
hostname to the guest.
Added a lock around DHCP config file frobbing, to avoid racing creation vs
deletion.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
loop driver stores only the first 64 chars of the filename). In this case, we
need to read through the store until we find the domain using the device, and
read the configured filename from there instead.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Use the IP address associated with the backend network interface
for connections from dom0 to the guest connected to this network
interface.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
CPUs a domains' vcpus can use. The older 'cpu' config option is
prepended to the list of cpus to use and will keep the behavior of
pinning VCPU0.
The cpus option supports ranges and negation, so:
cpus = "0-3,5,^1" produces -> [0,2,3,5]
The list is circular, so in a domain with the following config:
vcpus = 4
cpus = "0,3,7" # Use any of 0, 3, 7 for this domain.
would see vcpus 0-3 pinned to cpus 0,3,7,0 respectively.
Also, the pin operation is moved before the memory reservation as vcpu
to cpu mapping will be helpful for future NUMA work when trying to
allocate pages close to the physical cpus being used.
An update to the display of cpumap was needed to normalize the cpumap
values to the range of possible cpus.
I've also included some text for the xmdomain.cfg(5) man page.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
the check, reading from the store rather than /sys, and checking whether the
VM for apparently-conflicting uses is actually the same (i.e. this is a
migration or a reboot in progress).
This fixes recent failures in 12_block_attach_shared_domU and recloses bug #331.
This fix includes particularly skanky path slicing inside xenbus_probe, which
it would be nice to remove very soon.
The loopback device check still suffers from the problem that filenames over
64 characters long are truncated.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
the older hotplug infrastructure does not, so we must be able to serialise the
block-sharing checks (etc) ourselves.
Redirect stderr to /var/log/xen-hotplug.log, for better debugging.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
the appropriate entries into dom0's DHCP server configuration file, allowing
that server to provide info for the guest when it starts.
If an IP address is not configured for vif-nat, invent one using the domain
ID and vif ID.
Fix the vif-nat script.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
configured. Both of the files pick the same free loop device in the for
loop, and then one fails to losetup. This patch will now retry if
losetup fails until it succeeds or no more devices are available.
Signed-off-by: Robert Read <robert@xensource.com>
escape.
Allow the vif-nat and vif-route scripts to have netdev specified, rather than
hard-coding eth0.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
check_sharing functions have been rejigged slightly so that the file-specific
stuff can share the code therein. This separates the actual test from the
generation of the error message, and introduces the canonicalise_mode function.
This also restores the broken teardown functionality for file: devices -- the
writing of XENBUS_PATH/node had been removed, but this is required for file
device teardown.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
a device from two guests, or from dom 0 and a guest, can destroy the filesystem,
and this check prevents that. This should ensure that the xm tests
11_block_attach_shared_dom0 and 12_block_attach_shared_domU should pass.
Closes bug #331.
Devices may be shared only if all uses are read-only. If anyone has read-write
access to a device, then no sharing is allowed.
The mode in the config file may now have an exclamation mark appended, to
indicate that devices may be shared (i.e. that this new check should be
bypassed). This supports some network block devices, but is clearly dangerous
and should only be used when you know what you are doing.
The mode specified in the config file is now written explicitly to the store,
To implement this, the blkback driver has been changed to create two entries
in /sys describing each device in use. This means that we can determine which
devices are in use without crawling through the store.
The physical-device node has been changed to give the major and minor of the
device, separated by a colon. This means that we do not need to pack these
numbers into one, removing the restriction to 8 bit minors that we had in place
before.
The mode specified in the config file is now written explicitly to the store,
rather than using the presence or absence of a read-only node. This supports
the write-sharing override above.
If the device is in use, a new hotplug status of "busy" is written to the
store, and a message is written to a new hotplug-error node. Xend uses these
things for diagnosis.
The block scripts do not need to handle online or offline events, so this
support has been removed. These scripts can be called twice, depending upon
the hotplug config, so they now identify the second run and do not attempt to
set up the device again.
The device directories in the store are cleaned out before new details are
written there. This prevents stale information from messing up block device
hotplugging. This will be one cause of "blkback: changing physical device
not supported" messages.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
interface from the bridge when going offline -- the comment stating that
interfaces are auto-removed does not seem to be true, at least some of the
time. Log failure of brctl delif and ifconfig down only at debug level, as
this script may be called more than once, depending upon the hotplug
configuration.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
hotplug config, the offline event may come through to this script twice, and
the iptables -D will fail the second time.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
emerged as a problem in the field, AFAIK, but it seems that distro scripts
could have brought the device down already by this point (Debian stable's
net.agent does ifdown vifX.Y, and it wouldn't surprise me if someone decided
to do ifconfig vifX.Y down if this failed, for example).
Logging but ignoring the failure seems sensible.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Even though we are checking for a working iptables installation, it is still
possible that the user does not have the PHYSDEV matcher installed, so just
issue a diagnostic instead.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
the remove event, the script environment variable has disappeared, so we must
hook on the offline event instead. This fix was put into xen-backend.rules,
but not the vif scripts, so they were out of sync, and the interfaces were not
being properly closed down.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
before issuing the diagnostic about the missing vdev. Having a pdev but no
vdev is a strong indicator that the network-bridge script has run once already,
and so there is nothing to worry about. Having the vdev and no corresponding
pdev is still diagnosed.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
and udev. Pass all commands through from xen-backend.agent or
xen-backend.rules rather than second-guessing the individual scripts. This
should make it easier to tear down devices cleanly, especially the dangling
vifs we are seeing at the moment.
Cope with a missing type node inside the block script, as we don't want to
resurrect a removed node by writing a hotplug error message.
Log failure of iptables command.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
that packets between domU and the bridge are not firewalled, so if iptables is
not installed, then there is no worry.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
just like block device.
e.g. vif=['type=ioemu, mac=01:00:00:00:00:33, bridge=xenbr0']
type=ioemu to specify for vmx NIC device.
nics=4 can specify 4 vmx NIC now.
bridge is passed to device model now.
With this patch, the error
"Error: Device 0 (vif) could not be connected."
will not happen for creating vmx guest
currently, it happens on some linux distribution.
Signed-off-by: Xiaofeng Ling <xiaofeng.ling@intel.com>
When the serial port is redirect to pty, write the allocated
device to xenstore, then xm console can get it.
TODO:serial port by pty shall not block if there are no reading
on the other end
Signed-off-by: Xiaofeng Ling <xiaofeng.ling@intel.com>
ia64/VTI. Now ia64/vti will create links to arch/x86/dm/vmx_vioapic.c
and include/x86/vmx_vlapic.h.
Firstly, a small change to common virtual IOAPIC model to be used by
both sides. Also some compilation fix to tools is included in first
one. Secondly, there are ia64-specific changes to hook to common
IOAPIC model.
Based on this patch upon latest xen-ia64-unstable tip, we can see
multiple domains working again on XEN/IA64, including both domU and
VTI domain simultaneously in run-time.
Signed-off-by Kevin Tian <kevin.tian@intel.com>
Signed-off-by Anthony Xu <Anthony.xu@intel.com>
Signed-off-by Yunhong Jiang <yunhong.jiang@intel.com>
Signed-off-by Eddie Dong <eddie.dong@intel.com>
to 8. These interfaces are very cheap, so there's no problem having a few
spare. Anyone with more than 8 NICs can still use the kernel command line or
the module parameter line to pass a larger limit to this module.
Detail the kernel command line parameter for nloopbacks in the diagnostic in
network-bridge.
Closes bug #381.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
