Frequently Asked Questions

The following questions have been asked (and hopefully answered) at least once.

unix failed to install!

halvm-ghc is patently unable to compile the unix package, and anything that depends on it. There are a number of POSIX assumptions that do not make sense in a HaLVM context, such as a filesystem, processes, users, signals.

If unix is being sucked in as a transitive dependency on network, consider HaNS, our pure Haskell network stack. The network-hans shim package is mostly API-compatible with network, and a lucky porter may find it is a drop-in replacement.

If a filesystem is needed, access to Xen disks as block devices is available through the XenDevice library. There is also HalFS, though this has not been supported for quite some time.

Am I hosed if halvm-cabal install fails due to a missing C header file?

Not necessarily, but when you depend on a C library you have to be a bit careful. I think, for example, you can get zlib working by doing a little advanced prep: putting the header files somewhere that HaLVM can find them, making sure that the C zlib builds against HaLVM's libc, making sure to add the appropriate linker flags that get Cabal sorted out, etc.

Does the HaLVM support Cabal sandboxes?

In our experience, Cabal sandboxes work fine with the HaLVM. Stick to halvm-cabal, though.

EACCES / permissions problems and IVC / Rendezvous

Symptom: HaLVMs running the runLeftSide or runServer routines (found in in Communication.Rendezvous) are throwing EACCES and dying. This is a XenStore permissions problem.

Solution: The mkrenddir script must be run (as root, in Dom0) prior to using any IVC. mkrenddir creates a directory in the XenStore named /rendezvous and grants write permission to ordinary, unprivileged domains. The XenStore is transient, so mkrenddir should be run after every reboot, or prior to application launch.

I can't access my HaLVM WebServer / HaNS appliance!

Symptom: The HaLVM WebServer example (or some other HaNS device) compiles, runs, and obtains an IP address over some Xen bridge xenbr0, but cannot be reached from a browser / using the relevant TCP or UDP protocol.

Possible solution: Checksum offloading could lead to your packets being discarded. A quick fix involves disabling offloading for your bridge (xenbr0 here) using ethertool.

If you happen to be using Fedora's network service (and not NetworkManager), this involves appending the following line to your bridge definition:

ETHTOOL_OPTS=" --offload xenbr0 tx off rx off"