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

[Neil]

On Wed, Oct 3, 2012 at 8:52 PM, Juan Hernandez <jhernand at redhat.com> wrote:
> On 10/03/2012 05:00 PM, Neil wrote:
>> On Wed, Oct 3, 2012 at 4:41 PM, Itamar Heim <iheim at redhat.com> wrote:
>>> On 10/03/2012 04:37 PM, Neil wrote:
>>>>
>>>> On Wed, Oct 3, 2012 at 4:20 PM, Itamar Heim <iheim at redhat.com> wrote:
>>>>>
>>>>> On 10/03/2012 04:17 PM, Neil wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim <iheim at redhat.com> 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 at redhat.com> 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.

Just to update everyone, with the assistance from Juan I have managed
to complete the migration and I will send through the info on what was
done to the list asap.

Juan: If you wouldn't mind sending me the certificate re-generation
steps when you have a chance please

Thanks to everyone for their huge assistance!

Kind regards.

Neil Wilson.