Also NFS had locking issues on loopback. Not really possible to do this with NFS.
What is the issue with using a Gluster local replicate 1 for this?

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: ydary@redhat.com
IRC : ydary

On Wed, Dec 21, 2016 at 8:03 PM, Michal Skrivanek <mskrivan@redhat.com> wrote:
> On 21 Dec 2016, at 16:26, Martin Sivak <msivak@redhat.com> wrote:
>
> Hi,
>
>> Hope this get's in. This seems less overhead than a complete
>> hyperconverged gluster setup.
>
> But NFS still is a single point of failure. Hyperconverged is supposed
> to address that.
>
>>> In order to improve performance, disk I/O bound VMs can be pinned to
>>> a host with local storage. However there still is a performance
>>> drawback of NFS layers. Treating a local NFS storage as a local storage
>>> improves performance for VMs pinned to host.
>
> So VMs on one host will get better IO performance and the others will
> still use NFS as they do now.
>
> It is an interesting idea, I am just not sure if having poor-man's
> hyperconverged setup with all the drawbacks of NFS is worth it.
> Imagine for example what happens when that storage provider host needs
> to be fenced or put into maintenance. The whole cluster would go down
> (all VMs would lose storage connection, not just the VMs from the
> affected host).
>
> I will let someone from the storage team to respond to this, but I do
> not think that trading performance (each host has its own local
> storage) and resilience (well, at least one failing host does not
> affect the others) for migrations is a good deal.

If disk performance is critical then there is an option to use direct
access on local host using either PCI passthrough of a local storage
controller or SCSI passthrough of LUNs.

>
> --
> Martin Sivak
> SLA / oVirt
>
>> On Wed, Dec 21, 2016 at 2:18 PM, Sven Kieske <s.kieske@mittwald.de> wrote:
>>> On 21/12/16 11:44, Pavel Gashev wrote:
>>> Hello,
>>>
>>> I'd like to introduce a RFE that allows to use a local storage in multi
>>> server environments https://bugzilla.redhat.com/show_bug.cgi?id=1406412
>>>
>>> Most servers have a local storage. Some servers have very reliable
>>> storages with hardware RAID controllers and battery units.
>>>
>>> Example user cases:
>>> https://www.mail-archive.com/users@ovirt.org/msg36719.html
>>> https://www.mail-archive.com/users@ovirt.org/msg36772.html
>>>
>>> The best way to use local storage in multi server "shared" datacenters
>>> is exporting it over NFS. Using NFS allows to move disks and VMs among
>>> servers.
>>>
>>> In order to improve performance, disk I/O bound VMs can be pinned to
>>> a host with local storage. However there still is a performance
>>> drawback of NFS layers. Treating a local NFS storage as a local storage
>>> improves performance for VMs pinned to host.
>>>
>>> Currently setting up of NFS exports is out of scope of oVirt. However
>>> this would be a way to get rid of "Local/Shared" storage types of
>>> datacenter. So that all storages are shared, but local storages are
>>> used as local.
>>>
>>> Any questions/comments are welcome.
>>>
>>> Specifically I'd like to request for comment on potential data
>>> integrity issues during online VM or disk migration between NFS and
>>> localfs.
>>>
>>
>> Just let me say that I really like this as an end user.
>>
>> Hope this get's in. This seems less overhead than a complete
>> hyperconverged gluster setup.
>>
>>
>> --
>> Mit freundlichen Grüßen / Regards
>>
>> Sven Kieske
>>
>> Systemadministrator
>> Mittwald CM Service GmbH & Co. KG
>> Königsberger Straße 6
>> 32339 Espelkamp
>> T: +495772 293100
>> F: +495772 293333
>> https://www.mittwald.de
>> Geschäftsführer: Robert Meyer
>> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
>> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel