set up the networking, but now that we use ip directly, we don't need them, and
they were in any case broken when the ip address was specified without a suffix.
This work is by James Dykman <dykman@us.ibm.com>.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
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>
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>
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>
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>
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>
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>
The problem is: There is no mechanism to detect block device setup failure
Network devices have the same problem, and are fixed with this too.
I handling this problem in the way suggested by aliguori:
- hotplug scripts write a "hotplug-status" node on store
- Xend DevController.createDevice() check verify this node and return success
or throw an exception on failure.
- If no changes in "hotplug-status" node after DEVICE_CREATE_TIMEOUT seconds
Xend throw an exception showing the problem with hotplug scripts.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
code into vif-common.sh.
Fix the antispoofing in network-bridge to allow forwarding from physical
device to bridge, and vif0.0 to eth0.
Change the interface between netback driver and vif hotplugging scripts. The
mac address and bridge details are read from the store directly by the script,
so that the kernel driver does not need to get involved.
Remove an awful lot of cruft from vif-bridge. Move the iptables handling into
vif-common.sh, and fix it so that the new vif can get past the antispoofing
entries. Merge vif-nat and vif-route into this structure too.
Use ip instead of ifconfig to get necessary details.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Many files:
Make interface to network/block scripts consistent:
- output on stdout is returned to the script caller
- output on stderr is logged at the error level, messages with a '-' prefix
are logged at the debug level and messages with a '*' prefix are logged
at the info level.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
