Re: [ovirt-users] [ovirt-devel] hosted-engine setup/migration features for 3.6
Resending - inadvertently dropped CCs. On Wed, Dec 3, 2014 at 7:50 AM, Bob Doolittle b...@doolittle.us.com wrote: 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. So that page definitely needs attention. See: https://bugzilla.redhat.com/show_bug.cgi?id=105 https://bugzilla.redhat.com/show_bug.cgi?id=108 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. Regards, Bob On Wed, Dec 3, 2014 at 2:59 AM, Yedidyah Bar David d...@redhat.com 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 de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] [ovirt-devel] hosted-engine setup/migration features for 3.6
- Original Message - From: Bob Doolittle b...@doolittle.us.com To: Yedidyah Bar David d...@redhat.com 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=105 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=108 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 d...@redhat.com 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 de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel -- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] [ovirt-devel] hosted-engine setup/migration features for 3.6
- Original Message - From: Yedidyah Bar David d...@redhat.com To: Bob Doolittle b...@doolittle.us.com Cc: users users@ovirt.org, devel de...@ovirt.org 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 b...@doolittle.us.com To: Yedidyah Bar David d...@redhat.com 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=105 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. I now added another note next to the restore text. 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=108 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 d...@redhat.com 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 de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel -- Didi ___ Devel mailing list de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel Best, -- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
