[Users] Upgrade from 3.1
Itamar Heim
iheim at redhat.com
Wed Oct 2 06:36:49 UTC 2013
On 10/02/2013 12:40 AM, Christian Kolquist wrote:
> I am planning on testing the modify existing to become an export domain.
> That will only require me to copy within the isilon cluster a copy of
> the data which only will take about 1 hour. The plan is to do the
> following:
>
> 1. Load Fedora 19 on new engine server and install the engine, add new
> storage domain shares and get fully up and running without adding any nodes
just wondering - any reason you prefer fedora to .el6 (centos/rhel)?
> 2. shutdown all VM's and then remove the nodes
> 3. shutdown engine on current server
> 4. copy the existing storage domain to another location on the NAS and
> share it out over NFS.
> 5. Add nodes to new engine
> 6. Modify the copy of the storage domain to be an export domain
> (http://humblec.com/convert-master-data-domain-to-export-domain-in-a-crashed-rhevmovirt-setup/)
> 7. Add it in as an existing export domain on the new engine server and
> start import of VM's (will take probably 4-6 hours or maybe longer,
> total storage is ~1TB of data)
>
> Are there any further suggestions to this? If this plan fails then I
> will be able to revert back to the original engine server and domain.
sounds good to me
>
> Christian
>
>
>
>
> On Tue, Oct 1, 2013 at 10:48 AM, Itamar Heim <iheim at redhat.com
> <mailto:iheim at redhat.com>> wrote:
>
> On 10/01/2013 06:39 PM, Christian Kolquist wrote:
>
> We have a NFS storage cluster (Isilon) for the domain.
>
> The main question: is there a way to bring in an existing
> storage domain
> to a new engine without exporting it then importing it? This
> would be
> good for not just upgrades but also disaster recovery as well.
>
>
>
> yes, importing an existing data domain is a high priority for us for
> next version as the issue was raised several times by community users.
>
> for 3.3, there a few options (the first one is the cleanest)
> 1. "save the export part"
> - stop using the domain in 3.1
> - change its meta data to that of an export domain
> - import it as an existing export domain to 3.3
> - import the VMs
>
> 2. "re-create the VMs / import disks"
> - stop using the domain in 3.1
> - create a new (empty) domain in 3.3
> - move all disks to the new domain (assuming you create the new nfs
> export in a way allowing you to move, not copy, from the old export)
> - use the register disk api to add all disks
> - create VMs and associate the disks to them
>
> yes, this one requires to document first which disk is for which VM.
> i think someone scripted something around this option.
>
> if your disks have snapshots, this may become too complex.
>
> 3. re-create the VMs and override their disks.
> this was suggested several times in the past, but if you have
> snapshots, not relevant.
>
>
>
> On Tue, Oct 1, 2013 at 8:24 AM, Itamar Heim <iheim at redhat.com
> <mailto:iheim at redhat.com>
> <mailto:iheim at redhat.com <mailto:iheim at redhat.com>>> wrote:
>
> On 09/30/2013 04:55 PM, Christian Kolquist wrote:
>
> So, after many frustrating weekends of trying to
> upgrade ovirt
> from 3.1,
> I have come to the conclustion that it would just be
> best to
> export all
> of our VM's and Import them once I have redone the entire
> installation
> with FC19 and ovirt 3.3. Is there a way to export the
> entire domain
> easily? Or to bring the entire domain into a new
> install of the
> engine?
>
> Exporting a single VM takes a very long while. It
> would take a
> couple
> of days to export all of our VM's (33 total vm's using
> 1.017 TB
> of data)
> and then reimport them using the normal means of
> exporting the
> machines
> off then on to the export domain, load the new engine
> server
> then import
> them all back in.
>
>
> Any tips or tricks would be welcome.
>
>
> do you have a single data domain in the DC?
> is it nfs or something else?
>
>
>
> Christian
>
>
> FYI, I ran into just about every single bug that people
> had when
> upgrading from 3.1 to 3.2 and a few more. I can't
> spend any
> more time
> troubleshooting the upgrade process. If we can't do the
> export->import
> easily or migrate the current storage domain we will
> probably
> have to
> get rid of ovirt and move to another solution.
>
>
>
>
> ------------------------------____----------------------------__--__---
>
> This email, along with any attachments, is
> confidential. If you
> believe you received this message in error, please
> contact the
> sender immediately and delete all copies of the message.
> Thank you.
>
>
> ___________________________________________________
> Users mailing list
> Users at ovirt.org <mailto:Users at ovirt.org> <mailto:Users at ovirt.org
> <mailto:Users at ovirt.org>>
> http://lists.ovirt.org/____mailman/listinfo/users
> <http://lists.ovirt.org/__mailman/listinfo/users>
> <http://lists.ovirt.org/__mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>>
>
>
>
>
>
> ------------------------------__------------------------------__---
> This email, along with any attachments, is confidential. If you
> believe you received this message in error, please contact the
> sender immediately and delete all copies of the message.
> Thank you.
>
>
> _________________________________________________
> Users mailing list
> Users at ovirt.org <mailto:Users at ovirt.org>
> http://lists.ovirt.org/__mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
>
>
>
>
> ---------------------------------------------------------------
> This email, along with any attachments, is confidential. If you
> believe you received this message in error, please contact the
> sender immediately and delete all copies of the message.
> Thank you.
More information about the Users
mailing list