<p dir="ltr">Without knowing how the disks are split among the controllers, I don't want to make any assumptions about how shared it actually is, since it may be half and half with no multipathing.</p>
<p dir="ltr">While a multi-controller DAS array *may* be shared storage, it may not be. Moreover, I have no idea whether VDSM looks at by-path, by-bus, dm-*, or otherwise, and there are no guarantees that a SAS disk will present like a FC LUN (by-path/pci...-fc-$wwn...), whereas OCFS POSIXFS is assured to work, albeit with a more complex setup and another intermediary layer.</p>
<div class="gmail_quote">On Nov 17, 2013 10:00 AM, <<a href="mailto:users-request@ovirt.org">users-request@ovirt.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Send Users mailing list submissions to<br>
<a href="mailto:users@ovirt.org">users@ovirt.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:users-request@ovirt.org">users-request@ovirt.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:users-owner@ovirt.org">users-owner@ovirt.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: oVirt and SAS shared storage?? (Jeff Bailey)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sat, 16 Nov 2013 21:39:35 -0500<br>
From: Jeff Bailey <<a href="mailto:bailey@cs.kent.edu">bailey@cs.kent.edu</a>><br>
To: <a href="mailto:users@ovirt.org">users@ovirt.org</a><br>
Subject: Re: [Users] oVirt and SAS shared storage??<br>
Message-ID: <<a href="mailto:52882C67.9000707@cs.kent.edu">52882C67.9000707@cs.kent.edu</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
On 11/16/2013 9:22 AM, Ryan Barry wrote:<br>
><br>
> unfortunally, I didn't got a reply for my question. So.. let's try<br>
> again.<br>
><br>
> Does oVirt supports SAS shared storages (p. e. MSA2000sa) as<br>
> storage domain?<br>
> If yes.. what kind of storage domain I've to choose at setup time?<br>
><br>
> SAS is a bus which implements the SCSI protocol in a point-to-point<br>
> fashion. The array you have is the effective equivalent of attaching<br>
> additional hard drives directly to your computer.<br>
><br>
> It is not necessarily faster than iSCSI or Fiber Channel; almost any<br>
> nearline storage these days will be SAS, almost all the SANs in<br>
> production, and most of the tiered storage as well (because SAS<br>
> supports SATA drives). I'm not even sure if NetApp uses FC-AL drives<br>
> in their arrays anymore. I think they're all SAS, but don't quote me<br>
> on that.<br>
><br>
> What differentiates a SAN (iSCSI or Fiber Channel) from a NAS is that<br>
> a SAN presents raw devices over a fabric or switched medium rather<br>
> than point-to-point (point-to-point Fiber Channel still happens, but<br>
> it's easier to assume that it doesn't for the sake of argument). A NAS<br>
> presents network file systems (CIFS, GlusterFS, Lustre, NFS, Ceph,<br>
> whatever), though this also gets complicated when you start talking<br>
> about distributed clustered network file systems.<br>
><br>
> Anyway, what you have is neither of these. It's directly-attached<br>
> storage. It may work, but it's an unsupported configuration, and is<br>
> only shared storage in the sense that it has multiple controllers. If<br>
> I were going to configure it for oVirt, I would:<br>
><br>
<br>
It's shared storage in every sense of the word. I would simply use an<br>
FC domain and choose the LUNs as usual.<br>
<br>
> Attach it to a 3rd server and export iSCSI LUNs from it<br>
> Attach it to a 3rd server and export NFS from it<br>
> Attach it to multiple CentOS/Fedora servers, configure clustering (so<br>
> you get fencing, a DLM, and the other requisites of a clustered<br>
> filesystem), and use raw cLVM block devices or GFS2/OCFS filesystems<br>
> as POSIXFS storage for oVirt.<br>
><br>
<br>
These would be terrible choices for both performance and reliability.<br>
It's exactly the same as fronting an FC LUN would be with all of that<br>
crud when you could simply access the LUN directly. If the array port<br>
count is a problem then just toss an SAS switch in between and you have<br>
an all SAS equivalent of a Fibre Channel SAN. This is exactly what we<br>
do in production vSphere environments and there are no technical reasons<br>
it shouldn't work fine with oVirt.<br>
<br>
> Thank you for your help<br>
><br>
> Hans-Joachim<br>
><br>
><br>
> Hans<br>
><br>
> --<br>
> while (!asleep) { sheep++; }<br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
<br>
<br>
End of Users Digest, Vol 26, Issue 72<br>
*************************************<br>
</blockquote></div>