[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Provisioning SAN disk to domU's


  • To: "John Madden" <jmadden@xxxxxxxxxxx>
  • From: "Brandon Young" <bkyoung@xxxxxxxxx>
  • Date: Fri, 11 Jan 2008 14:22:09 -0600
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 11 Jan 2008 12:23:08 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=EJbAH86ApcYZ4aclE2NURG5Wyn+9LKysf4YK/qnts9zEaxx0N2Js69Qn6JKFOJQmEsU4O66HgmF7fj4+AB4NK9LGsPIZrZ8yZ7WRZNSirQiirl7Dlq0IFbMAZnaeQCyxD6IpZ9prgkMdQ0WuiSg34euPgQBo1w+lj2NfNX30XVQ=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

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:

> How do I go about giving a domU access to SAN?  Can we create SAN
> bridges like we can Ethernet bridges, and then define a virtual HBA in
> the domU?  Can we hide the real HBA from dom0 and present it to domU,
> somehow?  Is it even possible to do what I am asking?  After days of
> Googling and reading various documentation, plus reading hundreds of
> possibly relevant emails in this list's archive, I have not found what
> I am looking for.  I have more questions than answers.

If you want all of the i/o fencing capabilities (etc) of GFS, you'll
have to use the pciback/etc Xen stuff to give the HBA to the domU.
However, simply for GFS to work, I believe all you'd need to do is pass
the SAN LUN down to the domU via your Xen config (phy:/dev/sdX,...).
GFS works based on the fact that it's a SCSI disk, not so much on the
concept that it's "a SAN."

(Disclaimer: I haven't actually done this, it's just what seems
logical. :))

John




--
John Madden
Sr. UNIX Systems Engineer
Ivy Tech Community College of Indiana
jmadden@xxxxxxxxxxx

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.