On Tue, May 10, 2016 at 6:20 PM, Neal Gompa <ngompa13@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-faile...
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Didi