[ovirt-users] oVirt on a single server

Tue Sep 6 09:54:59 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.
>

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/
> 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
>
> _______________________________________________
> 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/20160906/7a088526/attachment-0001.html>