Re: [Users] fw: Migrating ovirt-engine to new server
- Original Message - > From: "Juan Hernandez" > To: "Johan Kragsterman" > Cc: users@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 t 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. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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 t 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-boun...@ovirt.org skrev: - > Till: Juan Hernandez > Från: Neil > Sänt av: users-boun...@ovirt.org > Datum: 2012.10.05 14:31 > Kopia: users@ovirt.org > Ärende: Re: [Users] fw: Migrating ovirt-engine to new server > > On Wed, Oct 3, 2012 at 8:52 PM, Juan Hernandez wrote: >> On 10/03/2012 05:00 PM, Neil wrote: >>> On Wed, Oct 3, 2012 at 4:41 PM, Itamar Heim wrote: >>>> On 10/03/2012 04:37 PM, Neil wrote: >>>>> >>>>> On Wed, Oct 3, 2012 at 4:20 PM, Itamar Heim wrote: >>>>>> >>>>>> On 10/03/2012 04:17 PM, Neil wrote: >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim 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 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" workin
Re: [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 t 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-boun...@ovirt.org skrev: - Till: Juan Hernandez Från: Neil Sänt av: users-boun...@ovirt.org Datum: 2012.10.05 14:31 Kopia: users@ovirt.org Ärende: Re: [Users] fw: Migrating ovirt-engine to new server On Wed, Oct 3, 2012 at 8:52 PM, Juan Hernandez wrote: > On 10/03/2012 05:00 PM, Neil wrote: >> On Wed, Oct 3, 2012 at 4:41 PM, Itamar Heim wrote: >>> On 10/03/2012 04:37 PM, Neil wrote: >>>> >>>> On Wed, Oct 3, 2012 at 4:20 PM, Itamar Heim wrote: >>>>> >>>>> On 10/03/2012 04:17 PM, Neil wrote: >>>>>> >>>>>> >>>>>> On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim 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 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.noar
Re: [Users] fw: Migrating ovirt-engine to new server
On Wed, Oct 3, 2012 at 8:52 PM, Juan Hernandez wrote: > On 10/03/2012 05:00 PM, Neil wrote: >> On Wed, Oct 3, 2012 at 4:41 PM, Itamar Heim wrote: >>> On 10/03/2012 04:37 PM, Neil wrote: On Wed, Oct 3, 2012 at 4:20 PM, Itamar Heim wrote: > > On 10/03/2012 04:17 PM, Neil wrote: >> >> >> On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim 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 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 p
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 wrote: >> On 10/03/2012 04:37 PM, Neil wrote: >>> >>> On Wed, Oct 3, 2012 at 4:20 PM, Itamar Heim wrote: On 10/03/2012 04:17 PM, Neil wrote: > > > On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim 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 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
Re: [Users] fw: Migrating ovirt-engine to new server
On Wed, Oct 3, 2012 at 4:41 PM, Itamar Heim wrote: > On 10/03/2012 04:37 PM, Neil wrote: >> >> On Wed, Oct 3, 2012 at 4:20 PM, Itamar Heim wrote: >>> >>> On 10/03/2012 04:17 PM, Neil wrote: On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim 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 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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [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 wrote: On 10/03/2012 04:17 PM, Neil wrote: On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim 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 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. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] fw: Migrating ovirt-engine to new server
On Wed, Oct 3, 2012 at 4:20 PM, Itamar Heim wrote: > On 10/03/2012 04:17 PM, Neil wrote: >> >> On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim 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 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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [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 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 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? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] fw: Migrating ovirt-engine to new server
On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim 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 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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] fw: Migrating ovirt-engine to new server
On 10/03/2012 03:28 PM, Neil wrote: Sorry to repost(kind of) but I'm really battling here and I need to get the VM's up and running again. I've given up on the idea of migrating the database across due to all sorts of problems encountered and I've instead done a completely NEW fresh ovirt-engine install and I've got one host added and running. How do I go about detaching my storage datacentre from my old ovirt-engine, and re-attaching it to my new ovirt-engine running on my new server? I'm running FC with multiple LUNS all assigned in one datacentre called "linux" and I can't detach it because it says "Cannot detach Storage Domain while VMs/Templates reside on it." My entire datacentre is in maintenance at the moment which consists of only 3 VM's(4TB's in total), my host only has a 16GB SDD in it, so exporting to a local NFS mount is not an option. Can I safely remove the VM's(as instructed above) by going to "VM's" and clicking remove and then will I be able to detach the datacentre and then re-attach it to the new ovirt-engine? Bearing in mind that I'm running a fresh install of ovirt-engine and I haven't copied the database across? Is it a matter of re-attaching the LUNS that are currently assigned because I can see the LUNS when I try and add a new FC storage domain, however the LUNS currently attached to the old ovirt-engine are greyed out and can't be selected. 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. Any assistance is greatly appreciated. Thank you. Regards. Neil Wilson. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] fw: Migrating ovirt-engine to new server
Sorry to repost(kind of) but I'm really battling here and I need to get the VM's up and running again. I've given up on the idea of migrating the database across due to all sorts of problems encountered and I've instead done a completely NEW fresh ovirt-engine install and I've got one host added and running. How do I go about detaching my storage datacentre from my old ovirt-engine, and re-attaching it to my new ovirt-engine running on my new server? I'm running FC with multiple LUNS all assigned in one datacentre called "linux" and I can't detach it because it says "Cannot detach Storage Domain while VMs/Templates reside on it." My entire datacentre is in maintenance at the moment which consists of only 3 VM's(4TB's in total), my host only has a 16GB SDD in it, so exporting to a local NFS mount is not an option. Can I safely remove the VM's(as instructed above) by going to "VM's" and clicking remove and then will I be able to detach the datacentre and then re-attach it to the new ovirt-engine? Bearing in mind that I'm running a fresh install of ovirt-engine and I haven't copied the database across? Is it a matter of re-attaching the LUNS that are currently assigned because I can see the LUNS when I try and add a new FC storage domain, however the LUNS currently attached to the old ovirt-engine are greyed out and can't be selected. Any assistance is greatly appreciated. Thank you. Regards. Neil Wilson. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
