[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Provisioning SAN disk to domU's
Thanks for the pointer to pciback. Your cleverly simple logic and statement of the obvious kicked my brain into gear. I needed that :-) I was possibly misusing the term "SAN" to mean yet-another-kind-of-network, rather than a-special-kind-of-disk. Viewing an HBA as analogous to a regular NIC, I extended the analogy by saying "An HBA would have a 'SAN bridge' like a NIC has an 'ethernet-bridge'." However, having pondered this for a few hours, I realize that's an idea that would not work well (at all?) when you get down to things like, oh, zoning the SAN switch, or something. So, it seems there really are only two ways to approach this problem: 1. Pass the (in my case) /dev/mpath/mpath* devices from dom0 to domU and pretend like I don't have an HBA in domU. 2. Use pciback to hide the HBA from dom0 and assign it to domU. Option #1, as you pointed out, does not give you I/O fencing, but would otherwise work fine. Additionally, you still have the flexibility to have additional LUNs attached to dom0 for things like VBDs on a SAN, etc, without having to add additional HBAs, but at the expense of performance. Option #2 is probably a better solution from the perspective of pure performance and correctness, at the expense of extra ... expense. I will now shame myself publicly by admitting that I was struggling with this problem because I was thinking about the problem in terms of volume groups and logical volumes, rather than physical LUNS. I couldn't figure out how the heck I was going to present the volume group to domU. Duh. Thanks for the help! -- Brandon On Jan 11, 2008 11:44 AM, John Madden <jmadden@xxxxxxxxxxx> wrote:
_______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |