On Fri, 2012-06-08 at 23:03 +0200, Olivier Doucet wrote: Hi Olivier, This is currently still a work in progress. I updated the wiki page a couple weeks ago with the latest status (and haven't managed to do any work on it since then). A basic summary: stateless works, but with some limitations. Limitations: 1. No swap or overcommit. We do not touch any disk at all, so there is no swap available, and thus no overcommit possible with a stateless node. 2. No local storage domain -- not a big deal since most deployments want shared storage of some sort, but same reasoning as #1 3. Limited support from engine/vdsm. This one is a bigger deal than #1 and #2. engine doesn't understand the concept of a stateless node, so it treats a stateless node the same as a stateful one. This results in the admin having to remove/re-add/re-approve the node on each reboot. All ISOs starting with 2.3.0 should have this support already. You simply need to add "stateless" (without quotes) to the kernel command line at boot, along with other auto-install parameters to configure the node and the host will be up and running. As for steps forward, we're currently focused almost entirely on getting a node based on F17 working right now. Once that is done and out the door, we'll re-visit this feature. If you're looking to get involved, some of the functionality for solving #1 and #2 is already available in the code. Basically, what needs to be done is add support in the TUI for AppVG and add some additional handling around AppVG in auto-install. As for #3, there isn't much left to do on the node itself, but we need a decision from the engine and vdsm teams on how they want to handle this long term. There are a few ways to do it, all of which have their own pros and cons. Mike