[ovirt-users] oVirt on a single server

Thu Sep 15 14:29:14 UTC 2016

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.

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

On Tue, Sep 6, 2016 at 12:54 PM, Yaniv Kaul <ykaul at redhat.com> wrote:

>
>
> 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.
>>
>
> If you have enough disk and bandwidth, perhaps it makes more sense to set
> up Gluster as a shared storage?
> And then just pin VMs to specific hosts, instead of separate DCs, etc.?
> Y.
>
>
>> 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/gl
>> uster/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/coc
>> kpit/
>> >>>>>> [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/nod
>> e/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
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20160915/df0a96c4/attachment-0001.html>