Re: [Users] fw: Migrating ovirt-engine to new server

On 10/03/2012 05:00 PM, Neil wrote: > On Wed, Oct 3, 2012 at 4:41 PM, Itamar Heim <iheim(a)redhat.com&gt; wrote: >> On 10/03/2012 04:37 PM, Neil wrote: >>> >>> On Wed, Oct 3, 2012 at 4:20 PM, Itamar Heim <iheim(a)redhat.com&gt; wrote: >>>> >>>> On 10/03/2012 04:17 PM, Neil wrote: >>>>> >>>>> >>>>> On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim <iheim(a)redhat.com&gt; wrote: >>>>>> >>>>>> >>>>>> On 10/03/2012 04:04 PM, Neil wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks for coming back to me. >>>>>>> >>>>>>> On Wed, Oct 3, 2012 at 4:00 PM, Itamar Heim <iheim(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> do you need to keep the VMs, or just move the LUNs to create a new >>>>>>>> one? >>>>>>>> if you just want to create a new one, you just need to clear the LUNs >>>>>>>> (DD >>>>>>>> over them) so engine will let you use them (or remove them from first >>>>>>>> engine >>>>>>>> which will format them for same end goal. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I need to keep the VM's unfortunately. >>>>>>> Logically speaking all I need to do is detach the main data domain >>>>>>> from one ovirt-engine and re-attach it to the new ovirt-engine. >>>>>> >>>>>> >>>>>> >>>>>> sadly, not that easy yet (though just discussed today the need to push >>>>>> this >>>>>> feature). >>>>>> >>>>>> easiest would be to export them to an nfs export domain, re-purpose the >>>>>> LUNs, and import to the new system. >>>>>> >>>>>> if not feasible, need to hack a bit probably. >>>>> >>>>> >>>>> >>>>> Oh crumbs! I thought that was wishful thinking though :) >>>>> >>>>> Exporting the VM's to NFS will take too long due to the total size >>>>> being 4TB and the VM's are a mail, proxy and pdc servers so getting >>>>> that much downtime won't be possible. Is attempting the upgrade >>>>> path(http://wiki.ovirt.org/wiki/OVirt_3.0_to_3.1_upgrade) again my >>>>> only option then? >>>>> Even if I manage to get the "upgrade" working will I still need to >>>>> export/import the VM's via NFS or will the datacentre move across once >>>>> it can be detached? >>>>> >>>> >>>> if you upgrade it the DC should be preserved. >>>> juan - i remember there was a specific issue around upgrade to check, but >>>> don't remember if was handled or not? >>> >>> >>> Okay that is good news at least, very glad to hear! >>> I am upgrading from a very early 3.1 release to the latest 3.1 using >>> the dreyou repo, but encountered an issue after importing my DB I >>> re-ran engine-setup and it kept asking for the engine password when it >>> got to the point of "upgrading schema". >>> >> >> oh, not sure - that depends on the various versions dreyou used. >> so this is 3.1-->3.1 (dreyou), not 3.0-->3.1? > > Correct, it's 3.1.0_0001-1.8.el6.x86_64 --> 3.1.0-3.19.el6.noarch, > and has no upgrade path. I'm also trying to separate my engine from > one of the hosts, as this was installed on one of the hosts as a test > and then we foolishy went live with it. > >>> An idea I've just thought of which might work, is if I allocate >>> additional LUNS(as I have spare drives inside the SAN) and mount it >>> locally on the new system, and then share this via NFS to the old >>> system as an export domain, then export the machines, then re-purpose >>> the old LUNS and add these as a new storage domain. Does this sound >>> like it might work? Logically it means the data is just copying from >>> one set of LUNS to the other but still remaining on the SAN. >> >> this should work. >> though you are still copying all the data via the host, regardless of being >> on same SAN. > > True! Sounds like the upgrade path is the best route. I have mailed > the developer of dreyou as I see there is a > patch(http://www.dreyou.org/ovirt/engine31.patch) which looks like it > corrects the issues encountered, but not sure how to apply it. > > The only "guide" I've got to work with is the > "OVirt_3.0_to_3.1_upgrade" not sure if this applies to me though > considering I'm going from 3.1 to 3.1. > > These are the steps I've tried. > > 1.) Install fresh ovirt-engine > 2.) Run through engine-setup using same parameters as old server Here make sure that the ovirt-engine service is stopped: service ovirt-engine stop > 3.) drop and import DB (http://wiki.ovirt.org/wiki/Backup_engine_db) Here, between step 3 and 4, you will need to update the database schema, as there were probably a lot of changes between the two versions that you are using. Go to the /usr/share/ovirt-engine/dbscripts directory and try to run the following script: ./upgrade.sh -U postgres Does that work? > 4.) Restore previous keystore and preserve .sh scripts > "http://wiki.ovirt.org/wiki/OVirt_3.0_to_3.1_upgrade" but not removing > the new ovirt-engine because it's a new install on separate system. Correct, that should work. > 5.) Re-run engine-setup keeping same parameters as before, which is > where it stops and keeps asking for the engine password when it tries > to upgrade the DB schema, despite the passwords being correct. No, you should not run engine-setup again, just start the ovirt-engine service again: service ovirt-engine start > Presumably once that works I can then shutdown my old DC, but do I > need to remove the VM's once it's in maitenance? When I tried before > it said "Cannot detach Storage Domain while VMs/Templates reside on > it." Please report back your results or ping me in the #ovirt channel if you have issues.