-
Notifications
You must be signed in to change notification settings - Fork 88
FAQ
The following questions have been asked (and hopefully answered) at least once.
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.
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.
In our experience, Cabal sandboxes work fine with the HaLVM.
Stick to halvm-cabal, though.
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.
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"