Is an effectively nested Xen Server storage repository a problem for stability?
Consider the graphic for the data path of the web server to a physical drive: (Starting on the right)
In the graphic Xen Server and the VM DRBD/NFS server is hosted on an internal USB flash drive. Hard drives are a local MDRAID10 array. The other VMs would be stored on a storage repo via NFS on a DRBD via a VDI attached as a block device on the MDRAID array. VMS are typically Debian. We DO NOT have a dedicated shared storage device (NAS, SAN, etc.).
If performance is not a concern (5-10 low use users for sporadic web access to a company site from the field), will there be stability concerns based on the data path being a storage repository served by another storage repository via NFS on DRBD.
TL;DR
In lieu of dual SANs with supporting networking, we are trying to use DRBD on two servers with local storage to allow for easy manual failover during an outage on the primary server. During an outage the secondary server would become the primary and the VMs could (theoretically) be instantly be fired up with very little configuration. The servers are same RAM and CPU generations even.
Xen seems to have its quirks and I forsee Xen Server having a problem that wipes out the entire server until it gets "fixed" given Xen is running EVERYTHING. I doubt we would have permanent data loss, but storage repositories disappearing happens more often than I would think based on the reading; and unless all your disaster recovery ducks are in a perfect little row, it could take a bit of time to bring things back up correctly if we had to reinstall Xen from scratch while carefully filling in the holes we were missing in our documentation as we went.
With DRBD thought, in the event of a problem we could be running on our backup server very quickly with active file and VM mirrors. Then worst case we could easily just start from scratch on the primary server if need be and not have to worry about "fixing" anything.
What is not shown are a couple more VMS to serve files, but the data would be housed on another SR, so only the VM data itself which is rather static would be served by the same path depicted in the graphic.