[ovirt-users] oVirt on a single server

Tue Sep 6 09:17:54 UTC 2016

Hi,

No, I move VMs around with an Export Storage domain. 

All NFS is exported only to the local machine.

Nothing is “shared” between hosts. But because I want to export VMs, we use “shared” storage in oVirt instead of “local”.

Best,

-- 

Dr Christophe Trefois, Dipl.-Ing.  
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine  
6, avenue du Swing 
L-4367 Belvaux  
T: +352 46 66 44 6124 
F: +352 46 66 44 6949  
http://www.uni.lu/lcsb

----
This message is confidential and may contain privileged information. 
It is intended for the named recipient only. 
If you receive it in error please notify me and permanently delete the original message and any copies. 
----

> On 06 Sep 2016, at 10:06, Yedidyah Bar David <didi at redhat.com> wrote:
> 
> On Tue, Sep 6, 2016 at 9:53 AM, Christophe TREFOIS
> <christophe.trefois at uni.lu> wrote:
>> 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.
> 
> Not sure I fully understand.
> 
> You use each of the 4 machines for both storage and running VMs?
> And export nfs on each to all the others?
> 
> So that if a VM needs more CPU/memory then disk IO, you can move
> it to another machine and hopefully get better performance even
> though the storage is not local?
> 
> I admit that it sounds very reasonable, and agree that doing this
> with nfs is easier than with iSCSI. If you don't mind the risk of
> local-nfs-mount locks, fine. As others noted, seems like it's quite
> a low risk.
> 
>> 
>> At this point we are not interested necessarily in HA.
>> 
>> Maybe for you that's the definition of a Dev environment as production has other attributes than just the type of storage?
> 
> Dev or Prod is for you to define :-)
> 
> How much time/money do you loose if a machine dies? If a machine
> locks up until someone notices and handles?
> 
>> 
>> Would be nice to hear your thoughts about this.
> 
> As wrote above, sounds reasonable if you understand the risks
> and can live with them.
> 
> Looking at the future you might want to check HC:
> 
> https://www.ovirt.org/develop/release-management/features/gluster/glusterfs-hyperconvergence/
> 
>> 
>> Kind regards,
>> Christophe
>> 
>> Sent from my iPhone
>> 
>>> On 06 Sep 2016, at 08:45, Yedidyah Bar David <didi at redhat.com> wrote:
>>> 
>>> On Tue, Sep 6, 2016 at 12:34 AM, Christophe TREFOIS
>>> <christophe.trefois at uni.lu> wrote:
>>>> So basically we need at least 2 nodes to enter the realm of testing and maintained?
>>> 
>>> I think some people occasionally use hosted-engine with local
>>> iSCSI storage on a single machine. AFAIK it's not tested by CI
>>> or often, but patches are welcome - e.g. using lago and
>>> ovirt-system-tests.
>>> 
>>> Can you please explain your intentions/requirements?
>>> 
>>> Even if it works, oVirt is not designed for single-machine
>>> _production_ use. For that, I think that most people agree that
>>> virt-manager is more suitable. oVirt on a single machine is
>>> usually for testing/demonstration/learning/etc.
>>> 
>>>> 
>>>> If we’re talking pure oVirt here.
>>>> 
>>>> --
>>>> 
>>>> Dr Christophe Trefois, Dipl.-Ing.
>>>> Technical Specialist / Post-Doc
>>>> 
>>>> UNIVERSITÉ DU LUXEMBOURG
>>>> 
>>>> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
>>>> Campus Belval | House of Biomedicine
>>>> 6, avenue du Swing
>>>> L-4367 Belvaux
>>>> T: +352 46 66 44 6124
>>>> F: +352 46 66 44 6949
>>>> http://www.uni.lu/lcsb
>>>> 
>>>> 
>>>> 
>>>> ----
>>>> This message is confidential and may contain privileged information.
>>>> It is intended for the named recipient only.
>>>> If you receive it in error please notify me and permanently delete the original message and any copies.
>>>> ----
>>>> 
>>>> 
>>>> 
>>>>> On 05 Sep 2016, at 16:31, Fernando Frediani <fernando.frediani at upx.com.br> wrote:
>>>>> 
>>>>> 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.
>>>>> 
>>>>> It is not nice to not have a All-in-One stable solution anymore as this can help with its adoption for later growth.
>>>>> 
>>>>> oVirt-Cockpit looks nice and intresting.
>>>>> 
>>>>> Fernando
>>>>> 
>>>>> 
>>>>>> On 05/09/2016 05:18, Barak Korren wrote:
>>>>>>> On 4 September 2016 at 23:45, zero four <zfnoctis at gmail.com> wrote:
>>>>>>> ...
>>>>>>> I understand and acknowledge that oVirt is not targeted towards homelab
>>>>>>> setups, or at least small homelab setups.  However I believe that having a
>>>>>>> solid configuration for such use cases would be a benefit to the project as
>>>>>>> a whole.
>>>>>> As others have already mentioned, using the full oVirt  with engine in
>>>>>> a single host scenario can work, but is not currently actively
>>>>>> maintained or tested.
>>>>>> 
>>>>>> There are other options originating from the oVirt community however.
>>>>>> 
>>>>>> One notable option is to use the Cockpit-oVirt plugin [1] which can
>>>>>> use VDSM to manage VMs on a single host.
>>>>>> 
>>>>>> Another option is to use the Kimchi project [2] for which discussion
>>>>>> for making it an oVirt project had taken part in the past [3]. It
>>>>>> seems that also some work for inclusion in oVirt node was also planned
>>>>>> at some point [4].
>>>>>> 
>>>>>> [1]: http://www.ovirt.org/develop/release-management/features/cockpit/
>>>>>> [2]: https://github.com/kimchi-project/kimchi
>>>>>> [3]: http://lists.ovirt.org/pipermail/board/2013-July/000921.html
>>>>>> [4]: http://www.ovirt.org/develop/release-management/features/node/kimchiplugin/
>>>>> 
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>> 
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/users
>>> 
>>> 
>>> 
>>> --
>>> Didi
> 
> 
> 
> -- 
> Didi