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

[Juan Hernandez]

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.


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.