From: "Yedidyah Bar David" <didi(a)redhat.com&gt; To: "Bob Doolittle" <bob(a)doolittle.us.com&gt; Cc: "users" <users(a)ovirt.org&gt;, "devel" <devel(a)ovirt.org&gt; Sent: Wednesday, December 3, 2014 3:04:17 PM Subject: Re: [ovirt-devel] hosted-engine setup/migration features for 3.6 ----- Original Message ----- > From: "Bob Doolittle" <bob(a)doolittle.us.com&gt; > To: "Yedidyah Bar David" <didi(a)redhat.com&gt; > Sent: Wednesday, December 3, 2014 2:50:12 PM > Subject: Re: [ovirt-devel] hosted-engine setup/migration features for 3.6 > > Another issue with that page is that it assumes a remote database. I am not > sure what percentage of cases have remote databases but clearly many > (most?) do not, since that's not default behavior. I agree. > So that page definitely > needs attention. See: > https://bugzilla.redhat.com/show_bug.cgi?id=1099995 Indeed. Note that this isn't specific to hosted-engine, it's the same for any migration using engine-backup to backup/restore, therefore there is a link to its page in the top, where this is more detailed.

We also have a bug [3] to automate this. [3] https://bugzilla.redhat.com/show_bug.cgi?id=1064503 > https://bugzilla.redhat.com/show_bug.cgi?id=1099998 > > Some of us have wanted to disable global maintenance upon bootup by adding > a systemd service on Fedora 20 (since you must enable global maintenance to > shut it down cleanly), and have found it impossible to create the necessary > systemd dependencies. It seems that (at least with 3.4) hosted-engine > --set-maintenance --mode=none will return an error for several seconds > after all other services have started and it's not clear what can be waited > upon in order to issue the command with assurance it will complete > successfully. This isn't strictly a setup/migration issue but it is an > issue with setting up a desired configuration with hosted-engine. The way > to reproduce this is simply to wait until gdm-greeter displays the login > prompt, ssh into the system and execute hosted-engine --set-maintenance > --mode=none and observe the error. Or create a systemd service that depends > upon (waits for) the latest-possible service, try executing the command > there, and observe the error. Ideally there would be some external > observable event which a systemd service could depend upon, when > hosted-engine is ready to do its thing. Adding Jiri for that. Do you have an open bug? Thanks, > > Regards, > Bob > > > On Wed, Dec 3, 2014 at 2:59 AM, Yedidyah Bar David <didi(a)redhat.com&gt; wrote: > > > Hi all, > > > > We already have quite a lot of open ovirt-hosted-engine-setup bugs for > > 3.6 > > [1]. > > > > Yesterday I tried helping someone on irc who planned to migrate to > > hosted-engine > > manually, and without knowing (so it seems) that such a feature exists. > > He > > had > > an engine set up on a physical host, prepared a VM for it, and asked > > about > > migrating > > the engine to the VM. In principle this works, but the final result will > > be a > > hosted-engine, where the engine manages a VM the runs itself, without > > knowing it, > > and without HA. > > > > The current recommended migration flow is described in [2]. This page is > > perhaps > > a bit outdated, perhaps missing some details etc., but principally works. > > The main > > issue with it, AFAICT after discussing this a bit with few people, is > > that > > it > > requires a new clean host. > > > > I'd like to hear what people here think about such and similar flows. > > > > If you already had an engine and migrated to hosted-engine, what was > > good, > > what > > was bad, what would you like to change? > > > > If you plan such a migration, what do you find missing currently? > > > > [1] http://red.ht/1vle8Vv > > [2] http://www.ovirt.org/Migrate_to_Hosted_Engine > > > > Best, > > -- > > Didi > > _______________________________________________ > > Devel mailing list > > Devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > -- Didi _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel