infrastructure boostrap. (i.e engine start / autostart).
Hi, We decided to run the oVirt engine (Oracle flavor) outside the infrastructure. (Medium infrastructure, 10 Hosts, iSCSI storage arrays) We created a second, smaller infrastructure (Single host, local storage) for management (engine) and monitoring (nagios, Dell storage manager etc..) . . This secondary infrastructure's engine runs in the first infrastructure. So, If you picture it, we're facing a "bootstrap" cross-dependency problem where each engine need the other one to start. This is actually a design we had when we were using Xen (Oracle's). Xen provides the "xen create" command to start a VM, even w/o a manager. Bootstrap problem solved. We're moving to oVirt and I understand that oVirt does not support out-of-the-box starting a VM w/o the engine. I've found a workaround that seems to work and would like your advice : - keep a dump of XML of the engine VM # virsh -r dumpxml prodEngine > prodEngine.xml - When necessary use virsh to start the engine # virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf create prodEngine.xml The only visible problem is a warning at the VM that was started manually saying "Newer configuration for next run". A restart clears the warning and there's does not seem to be consequences with the VM that had been started from a dump xml. Note : I understand that there is the "self-hosted" engine architecture that solves that "bootstrap" problem. We're no into that for now. We had bad experience with that design in the past.
On 4. 11. 2022, at 10:49, duparchy@esrf.fr wrote:
Hi,
We decided to run the oVirt engine (Oracle flavor) outside the infrastructure. (Medium infrastructure, 10 Hosts, iSCSI storage arrays) We created a second, smaller infrastructure (Single host, local storage) for management (engine) and monitoring (nagios, Dell storage manager etc..) . . This secondary infrastructure's engine runs in the first infrastructure.
So, If you picture it, we're facing a "bootstrap" cross-dependency problem where each engine need the other one to start.
This is actually a design we had when we were using Xen (Oracle's). Xen provides the "xen create" command to start a VM, even w/o a manager. Bootstrap problem solved.
We're moving to oVirt and I understand that oVirt does not support out-of-the-box starting a VM w/o the engine.
I've found a workaround that seems to work and would like your advice :
- keep a dump of XML of the engine VM # virsh -r dumpxml prodEngine > prodEngine.xml
- When necessary use virsh to start the engine # virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf create prodEngine.xml
there' libvirt where you can do anything as you wish. The complexity is with network and storage preparation, that's why we need ovirt-engine because all the configuration and logic is there. You can run suff manually but then you have to handle all that yourself too. E.g. what happens if the VM dies, what happens if storage becomes disconnected, how do you connect it after host boot, etc. That's what self-hosted engine feature does. It's not without its own issues, but it's there to care of all these cases
The only visible problem is a warning at the VM that was started manually saying "Newer configuration for next run". A restart clears the warning and there's does not seem to be consequences with the VM that had been started from a dump xml.
Note : I understand that there is the "self-hosted" engine architecture that solves that "bootstrap" problem. We're no into that for now. We had bad experience with that design in the past.
with oVirt or elsewhere? Thanks, michal
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/E2WM2N7G5VVIXI...
Thanks for your reply
with oVirt or elsewhere?
That was with XEN, OCFS2 cluster context, which is more prone to instabilities. Anyway, loosing the manager/engine when things start going wrong is just worsening the situation.
On 4. 11. 2022, at 15:03, duparchy@esrf.fr wrote:
Thanks for your reply
with oVirt or elsewhere?
That was with XEN, OCFS2 cluster context, which is more prone to instabilities. Anyway, loosing the manager/engine when things start going wrong is just worsening the situation.
Yes, but oVirt does that quite differently. Despite the challenges around deployment I believe it's a way safer solution than trying to run this independently/manually. Thanks, michal
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/MR72VXWOPYNSNK...
Hi, I checked the self-hosted doc and I see that High-Availability is provided by additional "self-hosted" capable hosts and a dedicated shared Storage Domain to store the engine VM. What about the "upgrade-gone-wrong" case ? I mean, before any important upgrade of any VM, we take a snapshot and revert to it if required. We had a similar case when upgrading the engine from 4.3 to 4.4, where a mismatched cluster CPU type prevented starting VMs. We were even working with two different engine VMs rather than snapshots because 4.3 was on OL7 et 4.4 is on OL8. We had to revert for a while to the 4.3 engine waiting for the fix. What's the plan w/ a self-hosted engine ? *Laurent Duparchy* *ESRF - The European Synchrotron MIS Unit 04 76 88 22 56* Michal Skrivanek wrote on 04/11/2022 15:43:
On 4. 11. 2022, at 15:03,duparchy@esrf.fr wrote:
Thanks for your reply
with oVirt or elsewhere? That was with XEN, OCFS2 cluster context, which is more prone to instabilities. Anyway, loosing the manager/engine when things start going wrong is just worsening the situation. Yes, but oVirt does that quite differently. Despite the challenges around deployment I believe it's a way safer solution than trying to run this independently/manually.
Thanks, michal
_______________________________________________ Users mailing list --users@ovirt.org To unsubscribe send an email tousers-leave@ovirt.org Privacy Statement:https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct:https://www.ovirt.org/community/about/community-guidelines/ List Archives:https://lists.ovirt.org/archives/list/users@ovirt.org/message/MR72VXWOPYNSNK...
participants (3)
-
duparchy＠esrf.fr -
Laurent Duparchy
-
Michal Skrivanek