<p dir="ltr">Without knowing how the disks are split among the controllers, I don&#39;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,  &lt;<a href="mailto:users-request@ovirt.org">users-request@ovirt.org</a>&gt; 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 &#39;help&#39; 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 &quot;Re: Contents of Users digest...&quot;<br>
<br>
<br>
Today&#39;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 &lt;<a href="mailto:bailey@cs.kent.edu">bailey@cs.kent.edu</a>&gt;<br>
To: <a href="mailto:users@ovirt.org">users@ovirt.org</a><br>
Subject: Re: [Users] oVirt and SAS shared storage??<br>
Message-ID: &lt;<a href="mailto:52882C67.9000707@cs.kent.edu">52882C67.9000707@cs.kent.edu</a>&gt;<br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
On 11/16/2013 9:22 AM, Ryan Barry wrote:<br>
&gt;<br>
&gt;     unfortunally, I didn&#39;t got a reply for my question. So.. let&#39;s try<br>
&gt;     again.<br>
&gt;<br>
&gt;     Does oVirt supports SAS shared storages (p. e. MSA2000sa) as<br>
&gt;     storage domain?<br>
&gt;     If yes.. what kind of storage domain I&#39;ve to choose at setup time?<br>
&gt;<br>
&gt; SAS is a bus which implements the SCSI protocol in a point-to-point<br>
&gt; fashion. The array you have is the effective equivalent of attaching<br>
&gt; additional hard drives directly to your computer.<br>
&gt;<br>
&gt; It is not necessarily faster than iSCSI or Fiber Channel; almost any<br>
&gt; nearline storage these days will be SAS, almost all the SANs in<br>
&gt; production, and most of the tiered storage as well (because SAS<br>
&gt; supports SATA drives). I&#39;m not even sure if NetApp uses FC-AL drives<br>
&gt; in their arrays anymore. I think they&#39;re all SAS, but don&#39;t quote me<br>
&gt; on that.<br>
&gt;<br>
&gt; What differentiates a SAN (iSCSI or Fiber Channel) from a NAS is that<br>
&gt; a SAN presents raw devices over a fabric or switched medium rather<br>
&gt; than point-to-point (point-to-point Fiber Channel still happens, but<br>
&gt; it&#39;s easier to assume that it doesn&#39;t for the sake of argument). A NAS<br>
&gt; presents network file systems (CIFS, GlusterFS, Lustre, NFS, Ceph,<br>
&gt; whatever), though this also gets complicated when you start talking<br>
&gt; about distributed clustered network file systems.<br>
&gt;<br>
&gt; Anyway, what you have is neither of these. It&#39;s directly-attached<br>
&gt; storage. It may work, but it&#39;s an unsupported configuration, and is<br>
&gt; only shared storage in the sense that it has multiple controllers. If<br>
&gt; I were going to configure it for oVirt, I would:<br>
&gt;<br>
<br>
It&#39;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>
&gt; Attach it to a 3rd server and export iSCSI LUNs from it<br>
&gt; Attach it to a 3rd server and export NFS from it<br>
&gt; Attach it to multiple CentOS/Fedora servers, configure clustering (so<br>
&gt; you get fencing, a DLM, and the other requisites of a clustered<br>
&gt; filesystem), and use raw cLVM block devices or GFS2/OCFS filesystems<br>
&gt; as POSIXFS storage for oVirt.<br>
&gt;<br>
<br>
These would be terrible choices for both performance and reliability.<br>
It&#39;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&#39;t work fine with oVirt.<br>
<br>
&gt;     Thank you for your help<br>
&gt;<br>
&gt;     Hans-Joachim<br>
&gt;<br>
&gt;<br>
&gt; Hans<br>
&gt;<br>
&gt; --<br>
&gt; while (!asleep) { sheep++; }<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Users mailing list<br>
&gt; <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
&gt; <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>