On Tue, May 10, 2016 at 6:20 PM, Neal Gompa <[email protected]> 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/users -- Didi _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
