9:17 a.m.
On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim <iheim(a)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(a)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?
Thanks!
Neil
9:20 a.m.
New subject: [Users] fw: Migrating ovirt-engine to new server
On 10/03/2012 04:17 PM, Neil wrote:
On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim <iheim(a)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(a)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?
9:37 a.m.
New subject: [Users] fw: Migrating ovirt-engine to new server
On Wed, Oct 3, 2012 at 4:20 PM, Itamar Heim <iheim(a)redhat.com> 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> 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> 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".
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.
Thanks!
Neil
9:41 a.m.
New subject: [Users] fw: Migrating ovirt-engine to new server
On 10/03/2012 04:37 PM, Neil wrote:
On Wed, Oct 3, 2012 at 4:20 PM, Itamar Heim <iheim(a)redhat.com>
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> 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>
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?
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.
10 a.m.
New subject: [Users] fw: Migrating ovirt-engine to new server
On Wed, Oct 3, 2012 at 4:41 PM, Itamar Heim <iheim(a)redhat.com> 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> 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> 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>
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
1:52 p.m.
New subject: [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>
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> 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>
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> 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.
7:31 a.m.
New subject: [Users] fw: Migrating ovirt-engine to new server
On Wed, Oct 3, 2012 at 8:52 PM, Juan Hernandez <jhernand(a)redhat.com> wrote:
On 10/03/2012 05:00 PM, Neil wrote:
> On Wed, Oct 3, 2012 at 4:41 PM, Itamar Heim <iheim(a)redhat.com> 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> 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>
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> 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.
10:03 a.m.
New subject: [Users] Procedure to change engine host name
Hi,
I see some interest on how to change the host name of the machine where
the engine runs (in release 3.1). This is a manual procedure that you
can use to do that:
0. Make a backup copy of the /etc/pki/ovirt-engine directory.
1. Regenerate the engine certificate signing request preserving the
existing private key (this is very important in order to avoid having to
decrypt/encrypt passwords stored in the database):
openssl req \
-new \
-subj '/C=US/O=Example Inc./CN=f17.example.com' \
-key /etc/pki/ovirt-engine/keys/engine_id_rsa \
-out /etc/pki/ovirt-engine/requests/engine.req
Replace "Example Inc." with the value that you provided during the
installation. If you don't forgot them they can be extracted from the
current engine certificate:
openssl x509 \
-in /etc/pki/ovirt-engine/certs/engine.cer \
-noout \
-subject
And *VERY IMPORTANT*, replace "f17.example.com" with the new fully
qualified host name.
2. Sign again the engine certificate, to simplify this the SignReq.sh
script should be used:
cd /etc/pki/ovirt-engine
./SignReq.sh \
engine.req \
engine.cer \
1800 \
/etc/pki/ovirt-engine \
`date -d yesterday +%y%m%d%H%M%S+0000` \
NoSoup4U
Double check that the generated certificate is correct, visually and
with the following command:
openssl verify \
-CAfile /etc/pki/ovirt-engine/ca.pem \
/etc/pki/ovirt-engine/certs/engine.cer
3. Generate also a DER encoded version of the certificate:
openssl x509 \
-in /etc/pki/ovirt-engine/certs/engine.cer \
-out /etc/pki/ovirt-engine/certs/engine.der \
-outform der
4. Export the engine private key and certificate to a PKCS12 file:
openssl pkcs12 \
-export \
-name engine \
-inkey /etc/pki/ovirt-engine/keys/engine_id_rsa \
-in /etc/pki/ovirt-engine/certs/engine.cer \
-out /etc/pki/ovirt-engine/keys/engine.p12 \
-passout pass:NoSoup4U
5. Regenerate the keystore used by the engine, importing the old CA
certificate and the new engine certificate:
rm -f /etc/pki/ovirt-engine/.keystore
keytool \
-keystore /etc/pki/ovirt-engine/.keystore \
-import \
-alias cacert \
-storepass mypass \
-noprompt \
-file /etc/pki/ovirt-engine/ca.pem
keytool \
-keystore /etc/pki/ovirt-engine/.keystore \
-importkeystore \
-srckeystore /etc/pki/ovirt-engine/keys/engine.p12 \
-srcalias engine \
-srcstoretype PKCS12 \
-srcstorepass NoSoup4U \
-srckeypass NoSoup4U \
-destalias engine \
-deststorepass mypass \
-destkeypass mypass
6. Restart the httpd and ovirt-engine services:
service ovirt-engine restart
service httpd restart
7. If using ovirt-node as the hypervisors then for each of then check
and fix the "vdc_host_name" parameter in the
"/etc/vdsm-reg/vdsm-reg.conf" file.
Note that this procedure will leave a small trace: the CA certificate
will still contain the URL of the old host. That is a minor
invonvenience, but to solve it *all* certificates would need to be
replaced. If there is interest I can prepare a procedure to do that as well.
Feedback is welcome.
Regards,
Juan Hernandez
--
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.
10:40 a.m.
New subject: [Users] fw: Migrating ovirt-engine to new server
Hi there...
Can't be possible that this is the procedure that we want to have to do this
operation...?
This is an operation that many users will want or will need to go through, and this
definitely seem toooo complex.
I suppose/hope there is a strategy for developing another more smooth solution?
What I would have thought is that it would have been a solution where you can add multiple
engines, and these would replicate the databases between them, and it would be easy to add
another one, or remove one....
Regards Johan
-----users-bounces(a)ovirt.org skrev: -----
Till: Juan Hernandez <jhernand(a)redhat.com>
Från: Neil
Sänt av: users-bounces(a)ovirt.org
Datum: 2012.10.05 14:31
Kopia: users(a)ovirt.org
Ärende: Re: [Users] fw: Migrating ovirt-engine to new server
On Wed, Oct 3, 2012 at 8:52 PM, Juan Hernandez <jhernand(a)redhat.com> wrote:
On 10/03/2012 05:00 PM, Neil wrote:
> On Wed, Oct 3, 2012 at 4:41 PM, Itamar Heim <iheim(a)redhat.com> 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> 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>
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> 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.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
6:08 a.m.
New subject: [Users] fw: Migrating ovirt-engine to new server
On 10/05/2012 05:40 PM, Johan Kragsterman wrote:
Hi there...
Can't be possible that this is the procedure that we want to have to do this
operation...?
This is an operation that many users will want or will need to go through, and this
definitely seem toooo complex.
You are right, it is more complex than what we all want to have, but at
the moment we don't have a simpler solution.
I suppose/hope there is a strategy for developing another more smooth
solution?
My particular view about this is that we should try to move as much as
possible to the database (certificates, for example, any kind of state
in general), so that when you have to move to a different server you
only need to install the packages in the new server and configure it to
use the old database.
What I would have thought is that it would have been a solution where
you can add multiple engines, and these would replicate the databases between them, and it
would be easy to add another one, or remove one....
Clustering is another thing we all want. We already can support high
availability configurations using additional clustering software. I
think that in addition to that we should also support active-active
configurations similar to what you describe, but as you can imagine
implementing that is really challenging.
Regards Johan
-----users-bounces(a)ovirt.org skrev: -----
Till: Juan Hernandez <jhernand(a)redhat.com>
Från: Neil
Sänt av: users-bounces(a)ovirt.org
Datum: 2012.10.05 14:31
Kopia: users(a)ovirt.org
Ärende: Re: [Users] fw: Migrating ovirt-engine to new server
On Wed, Oct 3, 2012 at 8:52 PM, Juan Hernandez <jhernand(a)redhat.com> wrote:
> On 10/03/2012 05:00 PM, Neil wrote:
>> On Wed, Oct 3, 2012 at 4:41 PM, Itamar Heim <iheim(a)redhat.com> 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>
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> 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> 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.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
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.
1:34 p.m.
New subject: [Users] fw: Migrating ovirt-engine to new server
----- Original Message -----
From: "Juan Hernandez" <jhernand(a)redhat.com>
To: "Johan Kragsterman" <johan.kragsterman(a)capvert.se>
Cc: users(a)ovirt.org
Sent: Saturday, October 6, 2012 1:08:12 PM
Subject: Re: [Users] fw: Migrating ovirt-engine to new server
On 10/05/2012 05:40 PM, Johan Kragsterman wrote:
> Hi there...
>
> Can't be possible that this is the procedure that we want to have
> to do this operation...?
>
> This is an operation that many users will want or will need to go
> through, and this definitely seem toooo complex.
You are right, it is more complex than what we all want to have, but
at
the moment we don't have a simpler solution.
> I suppose/hope there is a strategy for developing another more
> smooth solution?
My particular view about this is that we should try to move as much
as
possible to the database (certificates, for example, any kind of
state
in general), so that when you have to move to a different server you
only need to install the packages in the new server and configure it
to
use the old database.
Hi,
As there is a need to move configuration files anyway, PKI files are not exception.
I plan (if time permits) to re-write the whole PKI interface, to have a clean interface to
allow:
1. proper local management.
2. installation of CA in remote server.
3. integration with 3rd party PKI.
Regards,
Alon.
5:27 a.m.
New subject: [Users] Procedure to change engine host name
Hi Juan,
Thank you very much for sending through these details, I'm finally
getting around to trying to regenerate my certs now, but I'm
encountering an issue with importing the old CA as per below...
On Fri, Oct 5, 2012 at 5:03 PM, Juan Hernandez <jhernand(a)redhat.com> wrote:
5. Regenerate the keystore used by the engine, importing the old CA
certificate and the new engine certificate:
rm -f /etc/pki/ovirt-engine/.keystore
keytool \
-keystore /etc/pki/ovirt-engine/.keystore \
-import \
-alias cacert \
-storepass mypass \
-noprompt \
-file /etc/pki/ovirt-engine/ca.pem
[root@backup ovirt-engine]# rm -f /etc/pki/ovirt-engine/.keystore
[root@backup ovirt-engine]# keytool \
-keystore /etc/pki/ovirt-engine/.keystore \
-import \
-alias cacert \
-storepass mypass \
-noprompt \
-file /etc/pki/ovirt-engine/ca.pem
keytool error: java.lang.Exception: Input not an
X.509 certificate
My certificate was created on the early release of ovirt-engine 3.1 so
not sure if this is perhaps why?
Thanks.
Regards.
Neil Wilson.
4:06 a.m.
New subject: [Users] Procedure to change engine host name
Sorry to repost, anyone got any ideas here?
Thanks!
On Tue, Oct 16, 2012 at 12:27 PM, Neil <nwilson123(a)gmail.com> wrote:
Hi Juan,
Thank you very much for sending through these details, I'm finally
getting around to trying to regenerate my certs now, but I'm
encountering an issue with importing the old CA as per below...
On Fri, Oct 5, 2012 at 5:03 PM, Juan Hernandez <jhernand(a)redhat.com> wrote:
> 5. Regenerate the keystore used by the engine, importing the old CA
> certificate and the new engine certificate:
>
> rm -f /etc/pki/ovirt-engine/.keystore
>
> keytool \
> -keystore /etc/pki/ovirt-engine/.keystore \
> -import \
> -alias cacert \
> -storepass mypass \
> -noprompt \
> -file /etc/pki/ovirt-engine/ca.pem
[root@backup ovirt-engine]# rm -f /etc/pki/ovirt-engine/.keystore
[root@backup ovirt-engine]# keytool \
> -keystore /etc/pki/ovirt-engine/.keystore \
> -import \
> -alias cacert \
> -storepass mypass \
> -noprompt \
> -file /etc/pki/ovirt-engine/ca.pem
keytool error: java.lang.Exception: Input not an X.509 certificate
My certificate was created on the early release of ovirt-engine 3.1 so
not sure if this is perhaps why?
Thanks.
Regards.
Neil Wilson.
4:13 a.m.
New subject: [Users] Procedure to change engine host name
----- Original Message -----
From: "Neil" <nwilson123(a)gmail.com>
To: "Juan Hernandez" <jhernand(a)redhat.com>
Cc: users(a)ovirt.org
Sent: Wednesday, October 17, 2012 11:06:24 AM
Subject: Re: [Users] Procedure to change engine host name
Sorry to repost, anyone got any ideas here?
Thanks!
Can you check the certificate file for whitespaces, extra characters and etc.?
(In some threads about this issue that was usually the problem - apologize in advance if
you already read such threads....).
On Tue, Oct 16, 2012 at 12:27 PM, Neil <nwilson123(a)gmail.com>
wrote:
> Hi Juan,
>
> Thank you very much for sending through these details, I'm finally
> getting around to trying to regenerate my certs now, but I'm
> encountering an issue with importing the old CA as per below...
>
> On Fri, Oct 5, 2012 at 5:03 PM, Juan Hernandez
> <jhernand(a)redhat.com> wrote:
>> 5. Regenerate the keystore used by the engine, importing the old
>> CA
>> certificate and the new engine certificate:
>>
>> rm -f /etc/pki/ovirt-engine/.keystore
>>
>> keytool \
>> -keystore /etc/pki/ovirt-engine/.keystore \
>> -import \
>> -alias cacert \
>> -storepass mypass \
>> -noprompt \
>> -file /etc/pki/ovirt-engine/ca.pem
>
>
> [root@backup ovirt-engine]# rm -f /etc/pki/ovirt-engine/.keystore
> [root@backup ovirt-engine]# keytool \
>> -keystore /etc/pki/ovirt-engine/.keystore \
>> -import \
>> -alias cacert \
>> -storepass mypass \
>> -noprompt \
>> -file /etc/pki/ovirt-engine/ca.pem
> keytool error: java.lang.Exception: Input not an X.509 certificate
>
> My certificate was created on the early release of ovirt-engine 3.1
> so
> not sure if this is perhaps why?
>
> Thanks.
>
> Regards.
>
> Neil Wilson.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4:31 a.m.
New subject: [Users] Procedure to change engine host name
On Wed, Oct 17, 2012 at 11:13 AM, Oved Ourfalli <ovedo(a)redhat.com> wrote:
----- Original Message -----
> From: "Neil" <nwilson123(a)gmail.com>
> To: "Juan Hernandez" <jhernand(a)redhat.com>
> Cc: users(a)ovirt.org
> Sent: Wednesday, October 17, 2012 11:06:24 AM
> Subject: Re: [Users] Procedure to change engine host name
>
> Sorry to repost, anyone got any ideas here?
>
> Thanks!
>
Can you check the certificate file for whitespaces, extra characters and etc.?
(In some threads about this issue that was usually the problem - apologize in advance if
you already read such threads....).
Thanks for helping, I've just checked visually(using vi) and it seems
to be good, not sure if there is some kind of app I can run on it to
verify that is is valid. This is the first portion of the file, not
sure if there is something obvious?
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=Bla Bla, CN=CA-node02.blabla.com.49238
Validity
Not Before: May 22 18:41:23 2012
Not After : May 21 16:41:23 2022 GMT
Subject: C=US, O=Bla Bla, CN=CA-node02.blabla.com.49238
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
Thanks!
7:36 a.m.
New subject: [Users] Procedure to change engine host name
On 10/17/2012 02:36 PM, Neil wrote:
Sorry to repost, anyone got any ideas here?
Thanks!
On Tue, Oct 16, 2012 at 12:27 PM, Neil <nwilson123(a)gmail.com> wrote:
> Hi Juan,
>
> Thank you very much for sending through these details, I'm finally
> getting around to trying to regenerate my certs now, but I'm
> encountering an issue with importing the old CA as per below...
>
> On Fri, Oct 5, 2012 at 5:03 PM, Juan Hernandez <jhernand(a)redhat.com> wrote:
>> 5. Regenerate the keystore used by the engine, importing the old CA
>> certificate and the new engine certificate:
>>
>> rm -f /etc/pki/ovirt-engine/.keystore
>>
>> keytool \
>> -keystore /etc/pki/ovirt-engine/.keystore \
>> -import \
>> -alias cacert \
>> -storepass mypass \
>> -noprompt \
>> -file /etc/pki/ovirt-engine/ca.pem
>
>
> [root@backup ovirt-engine]# rm -f /etc/pki/ovirt-engine/.keystore
> [root@backup ovirt-engine]# keytool \
>> -keystore /etc/pki/ovirt-engine/.keystore \
>> -import \
>> -alias cacert \
>> -storepass mypass \
>> -noprompt \
>> -file /etc/pki/ovirt-engine/ca.pem
> keytool error: java.lang.Exception: Input not an X.509 certificate
The problem is probably that you are using the keytool from a Java 6
installation, and it doesn't support the PEM certificate format. You can
do two things to solve this:
1. Switch to Java 7 using "alternatives --config java". But this could
have adverse effects in other Java programs that you may be using. Note
that the oVirt engine is designed to use Java 7, so if you are using
Java 6 you can find other issues.
2. Create a DER encoded version of the CA certificate before importing it:
openssl x509 \
-in /etc/pki/ovirt-engine/ca.pem \
-inform pem \
-out /etc/pki/ovirt-engine/ca.cer \
-outform der
Then use the "ca.cer" file instead of the "ca.pem" file in the
keytool
command.
Sorry for the late response.
> My certificate was created on the early release of ovirt-engine
3.1 so
> not sure if this is perhaps why?
>
> Thanks.
>
> Regards.
>
> Neil Wilson.
--
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.
8:50 a.m.
New subject: [Users] Procedure to change engine host name
On Wed, Oct 17, 2012 at 2:36 PM, Juan Hernandez <jhernand(a)redhat.com> wrote:
1. Switch to Java 7 using "alternatives --config java". But
this could
have adverse effects in other Java programs that you may be using. Note
that the oVirt engine is designed to use Java 7, so if you are using
Java 6 you can find other issues.
No problem, this new machine is a dedicated ovirt-engine now and the
certificate was migrated from an older Centos install.
2. Create a DER encoded version of the CA certificate before
importing it:
openssl x509 \
-in /etc/pki/ovirt-engine/ca.pem \
-inform pem \
-out /etc/pki/ovirt-engine/ca.cer \
-outform der
Then use the "ca.cer" file instead of the "ca.pem" file in the
keytool
command.
Thanks, will give this a try tomorrow morning.
Sorry for the late response.
No problem, as usual your help is greatly appreciated!
Kind regards.
Neil Wilson.
11:38 a.m.
New subject: [Users] Procedure to change engine host name
On 10/05/2012 08:03 AM, Juan Hernandez wrote:
Hi,
I see some interest on how to change the host name of the machine where
the engine runs (in release 3.1). This is a manual procedure that you
can use to do that:
Thanks, Juan -- I'm sure this will come in handy!
I've copied these instructions into a page on the oVirt wiki:
http://wiki.ovirt.org/wiki/How_to_change_engine_host_name
Regards, Jason
0. Make a backup copy of the /etc/pki/ovirt-engine directory.
1. Regenerate the engine certificate signing request preserving the
existing private key (this is very important in order to avoid having to
decrypt/encrypt passwords stored in the database):
openssl req \
-new \
-subj '/C=US/O=Example Inc./CN=f17.example.com' \
-key /etc/pki/ovirt-engine/keys/engine_id_rsa \
-out /etc/pki/ovirt-engine/requests/engine.req
Replace "Example Inc." with the value that you provided during the
installation. If you don't forgot them they can be extracted from the
current engine certificate:
openssl x509 \
-in /etc/pki/ovirt-engine/certs/engine.cer \
-noout \
-subject
And *VERY IMPORTANT*, replace "f17.example.com" with the new fully
qualified host name.
2. Sign again the engine certificate, to simplify this the SignReq.sh
script should be used:
cd /etc/pki/ovirt-engine
./SignReq.sh \
engine.req \
engine.cer \
1800 \
/etc/pki/ovirt-engine \
`date -d yesterday +%y%m%d%H%M%S+0000` \
NoSoup4U
Double check that the generated certificate is correct, visually and
with the following command:
openssl verify \
-CAfile /etc/pki/ovirt-engine/ca.pem \
/etc/pki/ovirt-engine/certs/engine.cer
3. Generate also a DER encoded version of the certificate:
openssl x509 \
-in /etc/pki/ovirt-engine/certs/engine.cer \
-out /etc/pki/ovirt-engine/certs/engine.der \
-outform der
4. Export the engine private key and certificate to a PKCS12 file:
openssl pkcs12 \
-export \
-name engine \
-inkey /etc/pki/ovirt-engine/keys/engine_id_rsa \
-in /etc/pki/ovirt-engine/certs/engine.cer \
-out /etc/pki/ovirt-engine/keys/engine.p12 \
-passout pass:NoSoup4U
5. Regenerate the keystore used by the engine, importing the old CA
certificate and the new engine certificate:
rm -f /etc/pki/ovirt-engine/.keystore
keytool \
-keystore /etc/pki/ovirt-engine/.keystore \
-import \
-alias cacert \
-storepass mypass \
-noprompt \
-file /etc/pki/ovirt-engine/ca.pem
keytool \
-keystore /etc/pki/ovirt-engine/.keystore \
-importkeystore \
-srckeystore /etc/pki/ovirt-engine/keys/engine.p12 \
-srcalias engine \
-srcstoretype PKCS12 \
-srcstorepass NoSoup4U \
-srckeypass NoSoup4U \
-destalias engine \
-deststorepass mypass \
-destkeypass mypass
6. Restart the httpd and ovirt-engine services:
service ovirt-engine restart
service httpd restart
7. If using ovirt-node as the hypervisors then for each of then check
and fix the "vdc_host_name" parameter in the
"/etc/vdsm-reg/vdsm-reg.conf" file.
Note that this procedure will leave a small trace: the CA certificate
will still contain the URL of the old host. That is a minor
invonvenience, but to solve it *all* certificates would need to be
replaced. If there is interest I can prepare a procedure to do that as well.
Feedback is welcome.
Regards,
Juan Hernandez
--
@jasonbrooks
2:21 a.m.
New subject: [Users] Procedure to change engine host name
On Wed, Oct 17, 2012 at 3:50 PM, Neil <nwilson123(a)gmail.com> wrote:
On Wed, Oct 17, 2012 at 2:36 PM, Juan Hernandez
<jhernand(a)redhat.com> wrote:
> 1. Switch to Java 7 using "alternatives --config java". But this could
> have adverse effects in other Java programs that you may be using. Note
> that the oVirt engine is designed to use Java 7, so if you are using
> Java 6 you can find other issues.
Installed Java 1.7 and told my system to use it as you mentioned and
my certificate issue was resolved.
Thanks Juan, you the man!
Regards.
Neil Wilson.
11:12 a.m.
New subject: [Users] Procedure to change engine host name
On Wed, Oct 17, 2012 at 12:38 PM, Jason Brooks <jbrooks(a)redhat.com> wrote:
On 10/05/2012 08:03 AM, Juan Hernandez wrote:
> Hi,
>
> I see some interest on how to change the host name of the machine where
> the engine runs (in release 3.1). This is a manual procedure that you
> can use to do that:
>
I greatly appreciated these instructions, however there seems to be some
points missing. The links on the landing page (User Portal, Administrator
Portal, Reports Portal) still have my old host name in them. I can easily
work around this for the time being by clicking the link then manually
editing the URL of the failed page. I my efforts to find out where this
might have happen, I found 2 places in the database that include the old
host name:
*option_id.*VdcBootStrapUrl
*option_id.*VirtualMachineDomainName.
I have corrected those and restarted oVirt engine, but the links still have
the old address. So, I kept digging and found that there might be
references to the old host name in the storage_server_connections table,
e.g. ISOs. Of course, that won't affect these links.
Where else might I find references to the old name? Particularly for those
links?
Thanks!
Thanks, Juan -- I'm sure this will come in handy!
I've copied these instructions into a page on the oVirt wiki:
http://wiki.ovirt.org/wiki/**How_to_change_engine_host_name<http://wik...
I have put in a request for a wiki account and will update this page if I
am approved. Please feel free to update before I get to it. =)
11:26 a.m.
New subject: [Users] Procedure to change engine host name
On 11/12/2012 06:12 PM, Alan Johnson wrote:
On Wed, Oct 17, 2012 at 12:38 PM, Jason Brooks
<jbrooks(a)redhat.com
<mailto:jbrooks@redhat.com>> wrote:
On 10/05/2012 08:03 AM, Juan Hernandez wrote:
Hi,
I see some interest on how to change the host name of the
machine where
the engine runs (in release 3.1). This is a manual procedure
that you
can use to do that:
I greatly appreciated these instructions, however there seems to be some
points missing. The links on the landing page (User
Portal, Administrator Portal, Reports Portal) still have my old host
name in them. I can easily work around this for the time being by
clicking the link then manually editing the URL of the failed page. I
my efforts to find out where this might have happen, I found 2 places in
the database that include the old host name:
*option_id.*VdcBootStrapUrl
*option_id.*VirtualMachineDomainName.
I have corrected those and restarted oVirt engine, but the links still
have the old address. So, I kept digging and found that there might be
references to the old host name in the storage_server_connections table,
e.g. ISOs. Of course, that won't affect these links.
Where else might I find references to the old name? Particularly for
those links?
Thanks!
Thanks, Juan -- I'm sure this will come in handy!
I've copied these instructions into a page on the oVirt wiki:
http://wiki.ovirt.org/wiki/__How_to_change_engine_host_name
<http://wiki.ovirt.org/wiki/How_to_change_engine_host_name>
I have put in a request for a wiki account and will update this page if
I am approved. Please feel free to update before I get to it. =)
If you are using 3.1 check the /etc/ovirt-engine/web-conf.js file, it
contains the old host name as well.
--
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.
12:46 p.m.
New subject: [Users] Procedure to change engine host name
On Mon, Nov 12, 2012 at 12:26 PM, Juan Hernandez <jhernand(a)redhat.com>wrote:
On 11/12/2012 06:12 PM, Alan Johnson wrote:
> I greatly appreciated these instructions, however there seems to be some
> points missing. The links on the landing page (User
> Portal, Administrator Portal, Reports Portal) still have my old host
> name in them.
>
> Where else might I find references to the old name? Particularly for
> those links?
>
> Thanks!
If you are using 3.1 check the /etc/ovirt-engine/web-conf.js file, it
contains the old host name as well.
That was it. Thanks!
4194
days inactive
4234
days old
21 comments
8 participants
participants (8)
-
Alan Johnson -
Alon Bar-Lev -
Itamar Heim -
Jason Brooks -
Johan Kragsterman -
Juan Hernandez -
Neil -
Oved Ourfalli