If we can't determine the domU architecture, we assume it will be able to autonegotiate the block protocol correctly.

Very old 64-bit PV kernels had a bug where they would fail to negotiate
the 64-bit version of the block protocol. With a 32-bit domain 0 this
caused problems, so a workaround was added to the toolstack.

Recent xenctrl libraries have not got the function we need to determine
the domU architecture, so the workaround doesn't work.

If the workaround is unavailable we log and continue, rather than failing
to start the VM (which is almost certainlly going to work perfectly unless
it is very old)
Convert relative paths in the config file into absolute ones

Otherwise when we (eg) write a path into xenstore for udev, it
will fail to execute because udev has a different current working
directory.
Run the hotplug script manually for block devices (incremental commit)

We should switch away from relying on udev, like libxl has, to make
the code more portable
Read the path to setup-vif-rules from xenstore

Rather than statically 'sed' the vif udev script we take the
configured value from the config file and write that to
xenstore. The vif script reads this value dynamically.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Path to network.conf in config file; search for xenstore-read etc in several directories

Two linked problems were preventing the VIF udev script from running:
1. the path to network.conf was hardcoded in setup-vif-rules
   We now specify this path in the xenopsd config file, write it to xenstore
   and the vif script reads it
2. the setup-vif-script needs to run binaries (such as xenstore-read)
   which end up on different directories on different platforms.
   We now use /usr/bin/env and supply a PATH override (since we don't
   trust the PATH given to us by udev)

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Add a default network.conf (for bridge)
By default we will *not* use the hotplug/udev scripts (incremental commit)

However if we're still on xen 4.1 we will override the setting and attempt
to use the hotplug scripts.
If we have use_hotplug_scripts=false, then write libxl/disable_udev to disable the system scripts
Run the hotplug scripts from xenopsd, like libxl would.

Note in the VIF case we wait for the backend to switch to state=2
by which time the backend vif device should have been created.

Note we've added the same 'hack' to the vif script to prevent
the script running twice.
Switch from use_hotplug_scripts (meaning use udev) to run_hotplug_scripts (meaning do it ourselves), to match the semantics of libxl
xenopsd config file: strip enclosing " or ' in the values

Note we don't currently do any un-escaping: everything up to the end of
the string is considered part of the value. This means it is still not
possible to include paths which actually contain newlines... however this
can always be worked around with symlinks.

fixes xen-org/xenopsd#3
pygrub: make sure /var/run/xend/boot exists before calling pygrub

necessary but not sufficient for xen-org/xenopsd#5
pygrub: add compatibility with upstream pygrub

We only supply the --extra_args and --default_args if they are not ""
  -- these haven't been used since the upgrade to pygrub in XenEnterprise
     and this code could probably just be deleted altogether.

We only supply the --vm parameter if we are running eliloader
  -- eliloader needs this to fiddle with the VM state. pygrub doesn't
     need any VM information at all.

fixes xen-org/xenopsd#5
qemu-dm-wrapper: look for qemu-dm in /usr/lib/xen-4.2/bin as well
qemu-dm-wrapper: search for xenstore-write in /sbin:/usr/sbin:/bin:/usr/bin

fixes xen-org/xenopsd#2
qemu-dm-wrapper: fix setrlimit when the existing hardlimit is < our proposed soft limit

Patch provided by James Bulpin <james.bulpin@citrix.com>

fixes xen-org/xenopsd#1
Add experimental xenopsd.obuild
Use Memory_{interface,client} from xcp.memory
Update OASIS
Add an .obuild file