[ovirt-users] oVirt All-in-One upgrade path and requested improvements

[Yedidyah Bar David]

On Tue, May 10, 2016 at 6:20 PM, Neal Gompa <ngompa13 at gmail.com> wrote:
> Hello,
>
> I recently found out that oVirt "deprecated" the All-in-One
> configuration option in oVirt 3.6 and removed it in oVirt 4.0. This is
> a huge problem for me, as it means that my oVirt machines don't have
> an upgrade path.
>
> My experiments with the self-hosted engine have ended in failure for a
> couple of reasons:
> * The hosted engine deploy expects that a FQDN is already paired with
> an IP address. This is obviously false in most home environments, and
> even in the work environment where I use oVirt regularly. There's no
> workaround for this (except having a third machine to run the
> engine!), and this utterly breaks the only way to use oVirt in a
> DHCP-centric environment where I may not control the network
> addressing.

There is a simple workaround:

1. Pick up an FQDN for the engine
2. Add a relevant line to /etc/hosts on the host, with a fake
IP address
3. After the engine VM is up and you know its IP address, fix
the line in /etc/hosts to map to the real address. Also add the
same line to /etc/hosts on the engine vm (and all other hosts).

I agree it's ugly, but I use this quite a lot when I have to.

>
> * Other error states have caused the whole thing to break and just
> leave the system a broken mess. With no way to clean up, I'm left
> guessing how to undo everything, which is hellish and leads me to just
> wipe the whole system and start over.

Unlike engine-setup, which is used also for upgrades, hosted-engine
--deploy is ran only for a clean install, so reinstalling the host
is much easier than implementing full rollback as in engine-setup.

See also:

https://bugzilla.redhat.com/show_bug.cgi?id=1001181
http://www.ovirt.org/documentation/how-to/hosted-engine/#recoving-from-failed-install

>
> In addition, I was hoping that there would be improvements with the
> single system case, rather than destruction of this capability. Some
> of the improvements are things I think would be useful in even a
> multi-node setup, too.
>
> For example, I would like to see live migration capabilities with
> local storage across datacenters, as this capability in vMotion makes
> deployments a lot more flexible. Sometimes, local storage is really
> the only way to get the kind of speed needed for some workloads, and
> being able to offer some kind of HA for VMs on local storage would be
> excellent. In addition to being useful for all-in-one setups, it's
> quite useful for self-hosted engine configurations, too.
>
> It's also rather irritating that there's no way to migrate stuff from
> shared storage to local storage and back. On top of that, datacenters
> that have local storage can't have shared storage or vice versa.
>
> On top of that, it looks like the all-in-one code is being kept around
> anyway for the oVirt Live stuff, so why not just keep the capability
> and improve it? oVirt should become the best virtualization solution
> for everyone, not just people who have access to huge datacenters
> where all the conditions are perfect.

You mention several different issues, some unrelated or even irrelevant
to all-in-one. I'd suggest opening a thread and/or RFE per each. I'll not
personally comment because it's not my expertise.

For all-in-one, I tend to agree with Nir: What's wrong with virt-manager?

>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users



-- 
Didi