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

Neil nwilson123 at gmail.com
Wed Oct 3 15:00:56 UTC 2012


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
3.) drop and import DB (http://wiki.ovirt.org/wiki/Backup_engine_db)
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.
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.

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."

Thank you!

Neil



More information about the Users mailing list