<div dir="ltr">Also NFS had locking issues on loopback. Not really possible to do this with NFS.<div>What is the issue with using a Gluster local replicate 1 for this?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><pre cols="72"><span style="font-family:arial,helvetica,sans-serif">Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: <a href="mailto:ydary@redhat.com" target="_blank">ydary@redhat.com</a>
IRC : ydary</span></pre>
</div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Dec 21, 2016 at 8:03 PM, Michal Skrivanek <span dir="ltr"><<a href="mailto:mskrivan@redhat.com" target="_blank">mskrivan@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On 21 Dec 2016, at 16:26, Martin Sivak <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>> wrote:<br>
><br>
> Hi,<br>
<span class="">><br>
>> Hope this get's in. This seems less overhead than a complete<br>
>> hyperconverged gluster setup.<br>
><br>
</span><span class="">> But NFS still is a single point of failure. Hyperconverged is supposed<br>
> to address that.<br>
><br>
</span><span class="">>>> In order to improve performance, disk I/O bound VMs can be pinned to<br>
>>> a host with local storage. However there still is a performance<br>
>>> drawback of NFS layers. Treating a local NFS storage as a local storage<br>
>>> improves performance for VMs pinned to host.<br>
><br>
</span><span class="">> So VMs on one host will get better IO performance and the others will<br>
> still use NFS as they do now.<br>
><br>
> It is an interesting idea, I am just not sure if having poor-man's<br>
> hyperconverged setup with all the drawbacks of NFS is worth it.<br>
> Imagine for example what happens when that storage provider host needs<br>
> to be fenced or put into maintenance. The whole cluster would go down<br>
> (all VMs would lose storage connection, not just the VMs from the<br>
> affected host).<br>
><br>
> I will let someone from the storage team to respond to this, but I do<br>
> not think that trading performance (each host has its own local<br>
> storage) and resilience (well, at least one failing host does not<br>
> affect the others) for migrations is a good deal.<br>
<br>
</span>If disk performance is critical then there is an option to use direct<br>
access on local host using either PCI passthrough of a local storage<br>
controller or SCSI passthrough of LUNs.<br>
<span class="im HOEnZb"><br>
><br>
> --<br>
> Martin Sivak<br>
> SLA / oVirt<br>
><br>
>> On Wed, Dec 21, 2016 at 2:18 PM, Sven Kieske <<a href="mailto:s.kieske@mittwald.de">s.kieske@mittwald.de</a>> wrote:<br>
</span><div class="HOEnZb"><div class="h5">>>> On 21/12/16 11:44, Pavel Gashev wrote:<br>
>>> Hello,<br>
>>><br>
>>> I'd like to introduce a RFE that allows to use a local storage in multi<br>
>>> server environments <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1406412" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1406412</a><br>
>>><br>
>>> Most servers have a local storage. Some servers have very reliable<br>
>>> storages with hardware RAID controllers and battery units.<br>
>>><br>
>>> Example user cases:<br>
>>> <a href="https://www.mail-archive.com/users@ovirt.org/msg36719.html" rel="noreferrer" target="_blank">https://www.mail-archive.com/<wbr>users@ovirt.org/msg36719.html</a><br>
>>> <a href="https://www.mail-archive.com/users@ovirt.org/msg36772.html" rel="noreferrer" target="_blank">https://www.mail-archive.com/<wbr>users@ovirt.org/msg36772.html</a><br>
>>><br>
>>> The best way to use local storage in multi server "shared" datacenters<br>
>>> is exporting it over NFS. Using NFS allows to move disks and VMs among<br>
>>> servers.<br>
>>><br>
>>> In order to improve performance, disk I/O bound VMs can be pinned to<br>
>>> a host with local storage. However there still is a performance<br>
>>> drawback of NFS layers. Treating a local NFS storage as a local storage<br>
>>> improves performance for VMs pinned to host.<br>
>>><br>
>>> Currently setting up of NFS exports is out of scope of oVirt. However<br>
>>> this would be a way to get rid of "Local/Shared" storage types of<br>
>>> datacenter. So that all storages are shared, but local storages are<br>
>>> used as local.<br>
>>><br>
>>> Any questions/comments are welcome.<br>
>>><br>
>>> Specifically I'd like to request for comment on potential data<br>
>>> integrity issues during online VM or disk migration between NFS and<br>
>>> localfs.<br>
>>><br>
>><br>
>> Just let me say that I really like this as an end user.<br>
>><br>
>> Hope this get's in. This seems less overhead than a complete<br>
>> hyperconverged gluster setup.<br>
>><br>
>><br>
>> --<br>
>> Mit freundlichen Grüßen / Regards<br>
>><br>
>> Sven Kieske<br>
>><br>
>> Systemadministrator<br>
>> Mittwald CM Service GmbH & Co. KG<br>
>> Königsberger Straße 6<br>
>> 32339 Espelkamp<br>
>> T: <a href="tel:%2B495772%20293100" value="+495772293100">+495772 293100</a><br>
>> F: <a href="tel:%2B495772%20293333" value="+495772293333">+495772 293333</a><br>
>> <a href="https://www.mittwald.de" rel="noreferrer" target="_blank">https://www.mittwald.de</a><br>
>> Geschäftsführer: Robert Meyer<br>
>> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen<br>
>> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen<br>
>><br>
>><br>
</div></div><div class="HOEnZb"><div class="h5">>> ______________________________<wbr>_________________<br>
>> Devel mailing list<br>
>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
> ______________________________<wbr>_________________<br>
> Devel mailing list<br>
> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
><br>
><br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a></div></div></blockquote></div><br></div>