[ovirt-users] oVirt on a single server

Yedidyah Bar David didi at redhat.com
Tue Sep 6 09:45:26 UTC 2016


On Tue, Sep 6, 2016 at 12:17 PM, Christophe TREFOIS
<christophe.trefois at uni.lu> wrote:
> Hi,
>
> No, I move VMs around with an Export Storage domain.

OK.

>
> 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”.

I think you can use nfs export storage domains also in a local-storage DC.

>
> 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
>



-- 
Didi



More information about the Users mailing list