Get Xen vnode code to use a local blockstore rather than rolling its own
Since the Xen vnode code predates the blockstore code, it has its own strategy for figuring out which local disks to use to form an LVM VG to provide storage for vnodes. While the strategy is slightly different, we should attempt to get the Xen vnode path to use a blockstore. In addition to simplifying our life, it would enable (if exposed) the user to select a placement for the vnode storage. As an example, we had a user that wanted to use just the SSD in a machine to provide storage to the vnodes. This could be done on the node type in question by specifying a vnode blockstore with placement "sysvol". And eventually they would be able to specify the exact composition of the storage space.
Issues:
- Can we correctly size the blockstore in advance based on the number of vnodes and their storage requirements.
- Shared hosts configure the local storage as a RAID10 to provide more resilience (since they are likely to be running much, much longer than non-shared hosts). In the short term, we will have to not use a blockstore and fall back on the vnode code for this.
- How backward compatible will this be. In theory, since the vnode code will not attempt to create the VG if it already exists, we should just be able to setup a blockstore in advance and existing vnode code (i.e., Xen images) will just work. If it proves to be the case that there is some hole in that theory, we may have to add an osfeature to say that a Xen image is blockstore compatible, so that we know whether to try to set one up or not.