<div dir="ltr">I would suggest a local single brick gluster. This will probably be most simple and you can have a scale out option in this way to replica 3.</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 Tue, Sep 6, 2016 at 12:54 PM, Yaniv Kaul <span dir="ltr"><<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Sep 6, 2016 at 12:17 PM, Christophe TREFOIS <span dir="ltr"><<a href="mailto:christophe.trefois@uni.lu" target="_blank">christophe.trefois@uni.lu</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
No, I move VMs around with an Export Storage domain.<br></blockquote><div><br></div></span><div>If you have enough disk and bandwidth, perhaps it makes more sense to set up Gluster as a shared storage? </div><div>And then just pin VMs to specific hosts, instead of separate DCs, etc.?</div><span class="HOEnZb"><font color="#888888"><div>Y.</div></font></span><div><div class="h5"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
All NFS is exported only to the local machine.<br>
<br>
Nothing is “shared” between hosts. But because I want to export VMs, we use “shared” storage in oVirt instead of “local”.<br>
<br>
Best,<br>
<span><br>
--<br>
<br>
Dr Christophe Trefois, Dipl.-Ing.<br>
Technical Specialist / Post-Doc<br>
<br>
UNIVERSITÉ DU LUXEMBOURG<br>
<br>
LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE<br>
Campus Belval | House of Biomedicine<br>
6, avenue du Swing<br>
L-4367 Belvaux<br>
T: <a href="tel:%2B352%2046%2066%2044%206124" value="+3524666446124" target="_blank">+352 46 66 44 6124</a><br>
F: <a href="tel:%2B352%2046%2066%2044%206949" value="+3524666446949" target="_blank">+352 46 66 44 6949</a><br>
<a href="http://www.uni.lu/lcsb" rel="noreferrer" target="_blank">http://www.uni.lu/lcsb</a><br>
<br>
<br>
<br>
----<br>
This message is confidential and may contain privileged information.<br>
It is intended for the named recipient only.<br>
If you receive it in error please notify me and permanently delete the original message and any copies.<br>
----<br>
<br>
<br>
<br>
</span><div><div>> On 06 Sep 2016, at 10:06, Yedidyah Bar David <<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>> wrote:<br>
><br>
> On Tue, Sep 6, 2016 at 9:53 AM, Christophe TREFOIS<br>
> <<a href="mailto:christophe.trefois@uni.lu" target="_blank">christophe.trefois@uni.lu</a>> wrote:<br>
>> Personally my use case is that I have 4 machines with different specs and storage sizing. So I setup four DC with 1 host each. Then I have hosted engine on one of the hosts. Storage is local shared via NFS so that I can move VMs around.<br>
><br>
> Not sure I fully understand.<br>
><br>
> You use each of the 4 machines for both storage and running VMs?<br>
> And export nfs on each to all the others?<br>
><br>
> So that if a VM needs more CPU/memory then disk IO, you can move<br>
> it to another machine and hopefully get better performance even<br>
> though the storage is not local?<br>
><br>
> I admit that it sounds very reasonable, and agree that doing this<br>
> with nfs is easier than with iSCSI. If you don't mind the risk of<br>
> local-nfs-mount locks, fine. As others noted, seems like it's quite<br>
> a low risk.<br>
><br>
>><br>
>> At this point we are not interested necessarily in HA.<br>
>><br>
>> Maybe for you that's the definition of a Dev environment as production has other attributes than just the type of storage?<br>
><br>
> Dev or Prod is for you to define :-)<br>
><br>
> How much time/money do you loose if a machine dies? If a machine<br>
> locks up until someone notices and handles?<br>
><br>
>><br>
>> Would be nice to hear your thoughts about this.<br>
><br>
> As wrote above, sounds reasonable if you understand the risks<br>
> and can live with them.<br>
><br>
> Looking at the future you might want to check HC:<br>
><br>
> <a href="https://www.ovirt.org/develop/release-management/features/gluster/glusterfs-hyperconvergence/" rel="noreferrer" target="_blank">https://www.ovirt.org/develop/<wbr>release-management/features/gl<wbr>uster/glusterfs-hyperconvergen<wbr>ce/</a><br>
><br>
>><br>
>> Kind regards,<br>
>> Christophe<br>
>><br>
>> Sent from my iPhone<br>
>><br>
>>> On 06 Sep 2016, at 08:45, Yedidyah Bar David <<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>> wrote:<br>
>>><br>
>>> On Tue, Sep 6, 2016 at 12:34 AM, Christophe TREFOIS<br>
>>> <<a href="mailto:christophe.trefois@uni.lu" target="_blank">christophe.trefois@uni.lu</a>> wrote:<br>
>>>> So basically we need at least 2 nodes to enter the realm of testing and maintained?<br>
>>><br>
>>> I think some people occasionally use hosted-engine with local<br>
>>> iSCSI storage on a single machine. AFAIK it's not tested by CI<br>
>>> or often, but patches are welcome - e.g. using lago and<br>
>>> ovirt-system-tests.<br>
>>><br>
>>> Can you please explain your intentions/requirements?<br>
>>><br>
>>> Even if it works, oVirt is not designed for single-machine<br>
>>> _production_ use. For that, I think that most people agree that<br>
>>> virt-manager is more suitable. oVirt on a single machine is<br>
>>> usually for testing/demonstration/learning<wbr>/etc.<br>
>>><br>
>>>><br>
>>>> If we’re talking pure oVirt here.<br>
>>>><br>
>>>> --<br>
>>>><br>
>>>> Dr Christophe Trefois, Dipl.-Ing.<br>
>>>> Technical Specialist / Post-Doc<br>
>>>><br>
>>>> UNIVERSITÉ DU LUXEMBOURG<br>
>>>><br>
>>>> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE<br>
>>>> Campus Belval | House of Biomedicine<br>
>>>> 6, avenue du Swing<br>
>>>> L-4367 Belvaux<br>
>>>> T: <a href="tel:%2B352%2046%2066%2044%206124" value="+3524666446124" target="_blank">+352 46 66 44 6124</a><br>
>>>> F: <a href="tel:%2B352%2046%2066%2044%206949" value="+3524666446949" target="_blank">+352 46 66 44 6949</a><br>
>>>> <a href="http://www.uni.lu/lcsb" rel="noreferrer" target="_blank">http://www.uni.lu/lcsb</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> ----<br>
>>>> This message is confidential and may contain privileged information.<br>
>>>> It is intended for the named recipient only.<br>
>>>> If you receive it in error please notify me and permanently delete the original message and any copies.<br>
>>>> ----<br>
>>>><br>
>>>><br>
>>>><br>
>>>>> On 05 Sep 2016, at 16:31, Fernando Frediani <<a href="mailto:fernando.frediani@upx.com.br" target="_blank">fernando.frediani@upx.com.br</a>> wrote:<br>
>>>>><br>
>>>>> Adding Kimchi to oVirt node perhaps may be the easiest option. It can be pretty useful for many situations and doesn't need such thing like mounting NFS in localhost.<br>
>>>>><br>
>>>>> It is not nice to not have a All-in-One stable solution anymore as this can help with its adoption for later growth.<br>
>>>>><br>
>>>>> oVirt-Cockpit looks nice and intresting.<br>
>>>>><br>
>>>>> Fernando<br>
>>>>><br>
>>>>><br>
>>>>>> On 05/09/2016 05:18, Barak Korren wrote:<br>
>>>>>>> On 4 September 2016 at 23:45, zero four <<a href="mailto:zfnoctis@gmail.com" target="_blank">zfnoctis@gmail.com</a>> wrote:<br>
>>>>>>> ...<br>
>>>>>>> I understand and acknowledge that oVirt is not targeted towards homelab<br>
>>>>>>> setups, or at least small homelab setups. However I believe that having a<br>
>>>>>>> solid configuration for such use cases would be a benefit to the project as<br>
>>>>>>> a whole.<br>
>>>>>> As others have already mentioned, using the full oVirt with engine in<br>
>>>>>> a single host scenario can work, but is not currently actively<br>
>>>>>> maintained or tested.<br>
>>>>>><br>
>>>>>> There are other options originating from the oVirt community however.<br>
>>>>>><br>
>>>>>> One notable option is to use the Cockpit-oVirt plugin [1] which can<br>
>>>>>> use VDSM to manage VMs on a single host.<br>
>>>>>><br>
>>>>>> Another option is to use the Kimchi project [2] for which discussion<br>
>>>>>> for making it an oVirt project had taken part in the past [3]. It<br>
>>>>>> seems that also some work for inclusion in oVirt node was also planned<br>
>>>>>> at some point [4].<br>
>>>>>><br>
>>>>>> [1]: <a href="http://www.ovirt.org/develop/release-management/features/cockpit/" rel="noreferrer" target="_blank">http://www.ovirt.org/develop/r<wbr>elease-management/features/coc<wbr>kpit/</a><br>
>>>>>> [2]: <a href="https://github.com/kimchi-project/kimchi" rel="noreferrer" target="_blank">https://github.com/kimchi-proj<wbr>ect/kimchi</a><br>
>>>>>> [3]: <a href="http://lists.ovirt.org/pipermail/board/2013-July/000921.html" rel="noreferrer" target="_blank">http://lists.ovirt.org/piperma<wbr>il/board/2013-July/000921.html</a><br>
>>>>>> [4]: <a href="http://www.ovirt.org/develop/release-management/features/node/kimchiplugin/" rel="noreferrer" target="_blank">http://www.ovirt.org/develop/r<wbr>elease-management/features/nod<wbr>e/kimchiplugin/</a><br>
>>>>><br>
>>>>> ______________________________<wbr>_________________<br>
>>>>> Users mailing list<br>
>>>>> <a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
>>>>> <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> Users mailing list<br>
>>>> <a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
>>>> <a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Didi<br>
><br>
><br>
><br>
> --<br>
> Didi<br>
<br>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br>
</div></div></blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>