The "long-winded" way is the only way I know of doing it. https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/... Providing you plan in advance I don't think it's really that onerous. And it means you have a stable system going forward... ---- On Mon, 27 Jul 2020 16:07:13 +0100 Philip Brown <pbrown(a)medata.com&gt; wrote ---- I currently have a self-hosted engine, running in a dedicated ISCSI storage domain. I'd like to change the backend hardware for the storage. i think there's some longwinded and complicated method of shutting down the engine, backup, creating a NEW one, restore, and whoknowswhat. I was wondering though, if maybe there's a way to just add an iscsi lun to the storage domain, and tell ovirt, "Hey, move the stuff over to that other lun" ? Ive added the new lun already :) havent found a reference to move the files' residence though. If it helps, my end goal is to remove that lun completely. -- Philip Brown| Sr. Linux System Administrator | Medata, Inc. 5 Peters Canyon Rd Suite 250 Irvine CA 92606 Office 714.918.1310| Fax 714.918.1325 mailto:pbrown@medata.com| www.medata.com _______________________________________________ Users mailing list -- mailto:users@ovirt.org To unsubscribe send an email to mailto: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/522VCAWNK7S...

I managed to successfully do the migration of the iscsi storage domain for my hosted engine, from one host/target to another. For posterity, here's how it went for me, skipping a few failed attempts. Sorry for formatting Note #1: oVirt 4.3, using the ovirt supplied "node" images for hosts Note #2: this takes a really.. REALLY.. long time. over an hour. possibly closer to 2 hours. My Steps: ========== *. make sure that the hosted_engine vm is NOT running on node #1 of my cluster, so I have a fallback if I need it *. do a "engine-backup" from the hosted_engine vm command line, and scp the resulting 7mb file out to node #1 of my cluster *. create a new iscsi LUN for a new hosted_engine storage domain *. put the cluster in global maint, with hosted-engine --set-maintenance --mode=global *. shut down the hosted engine VM *. on node #1, do ovirt-hosted-engine-cleanup *. on node #1, systemctl enable firewalld; systemctl start firewalld and then doublecheck that firewalld --list-services showed all the good things, including ssh and cockpit *. on node #1, ovirt-hosted-engine-setup --restore-from-file=ovirt-engine-backup=ovirt-engine-backup-xxxxxxxxx *** note: NOT engine-backup --mode=restore after the fact. I'm glad I happened to stumble on this feature. I think. *. Press return a lot. Occasionally actually putting in specifics of things. - Side quest: Since I had no idea how I was supposed to set up the new iSCSI storage domain, I chose the option for .... Pause the execution after adding this host to the engine? You will be able to iteratively connect to the restored engine.. ....blahblah Turns out, this was NOT needed. but I got to learn a few things. such as, the install process RENAMES any existing storage domain called "hosted_storage" to "hosted_storage_old_xxxxxx" So, this may have a "point of no return" point *. Wait. A LOT output said something about wait until VM gets into run state. or maybe it was TASK [ovirt.engine-setup : Make sure `ovirt-engine` service is running] This took something like 10 minute or more, while giving ZERO feedback to me. I wondered if it had locked up or somthing, and was tempted to kill it, but instead, I eventually left for lunch. Good thing. *. notice that the process creates a TEMPORARY "external engine" VM.. that is maybe stored on host local disks or something? I dont know details. but this is what allowed me to connect in via browser and check out how things looked, when it prompted me that I could. *. When I was ready, remove the trigger file /tmp/somethingsomething (via a separate window ssh session) *. Answer a bunch more text prompts about what iSCSI host I want to connect to, and then which target to use, and then which lun. Finally, it got around to creating the new storage domain for hosted engine, on the new LUN. *** Fun fact ***. It just gives you lun sizes. It does not give you ACTUAL lun numbers for the target you select to use. Specifically, it showed me my "lun #2" as MENU CHOICE #1. So make sure you make all your luns slightly different sizes! Also, it has NO AWARENESS of EXISTING STORAGE DOMAINS. In fact, it silently overwrote a new storage domain I had called "hosted_storage", after I noticed that the prior one had been renamed *. Wait A long. time. I am happy to say that eventually, it actually finished up what it was doing. It then informed me that I had to go to each of the other hosts (through the hosted engine GUI) and individually 1. put the host in maintenance mode 2. choose Installation -> Reinstall AND manually reenable the Hosted engine install, for those hosts that I want it on again. I am happy to report that this went smoothly. Here ends my tale :) ----- Original Message ----- From: "Philip Brown" <pbrown(a)medata.com&gt; To: "Alan" <alan+ovirt(a)griff.me.uk&gt; Cc: "users" <users(a)ovirt.org&gt; Sent: Monday, July 27, 2020 11:39:39 AM Subject: Re: [ovirt-users] change lun for hosted_engine use? To someone who has never dealt with the backup/restore stuff.. not to mention taking over a previously setup cluster.. it is exceedingly onerous :( Those docs seem geared primarily towards doing backup and restore of a hosted_engine where nothing is changing. it would be really helpful to have docs where the goal is changing the environment for the hosted engine.