Is it possible to upgrade from 2.2 to 3.0?

Latest response

There are two major platform changes in RHEV 3.0

 

  1. RHEV Manager moved to RHEL
  2. RHEV Hypervisor is now based on RHEL 6

This prevents in place upgrade, however a migration is possible in most cases.  

 

Red Hat will provide migration tool and assistance to customers that wish to migrate their existing environment to RHEV 3.

 

An example (simplistic) flow will look like:

  1. Make sure your 2.2 is up to date with the latest Z-stream, both manager and guests drivers
  2. Prepare a server with clean installation of RHEV Manager 3.0
  3. Use the migration tool provided by Red Hat to move all the existing configuration to the new RHEV Manager
  4. At this point you will have fully functional RHEV 3.0 system, with all the existing clusters working in compatibility mode to 2.2.
  5. Next stage will be topgrade the hosts while moving them to a new cluster and then move the virtual machines to the new cluster.
    Note: There will be a grace period in which working in the compatibility mode clusters is supported (You can even add more resources like hosts and storage to these clusters) though you won't be able to enjoy the enhanced features and performance benefits of the RHEL 6 based hypervizors.  

Please stay tuned for more about this towards RHEV 3.0 GA

Responses

The first step has an important piece of info that should be stressed - the older guest drivers are not compatible with RHEL6.x hosts, so it is very important to update the VM guests (especially Windows guests) to the latest drivers on RHN, before migrating to RHEV3.x

Where can I find the migration tool?

It will be provided at GA upon request from 2.2 customers.

But where to request the tools?

The RHEV-M Migration Tool is in its final stages and is soon going to be released asyncronously on RHN. Other supporting resources are being coordinated (Documentations, KBASEs).

 

BTW: The Migration Tool will *only* migrate RHEV-M from 2.2 to 3.0. It will not migrate any hypervisors (please use the RHEL Hypervisor Guide for this) or storage domains.

 

Stay tuned! More info will be posted shortly...

 

Andrius.

Migration tool is still in testing phase and is currently in beta. This will be released in the near future.

 

If you have a TAM for your account, you can speak to him to get access to early version of the tool.

Any timeline as to when the migration tool will be ready?. We are looking to move to RHEV 3.0 as soon as possible.

 

Thanks.

Tejas,

 

Soon - the migration tool is still in test. Red Hat is currently ensuring it is ready for production environments, as well as includes all assocated documentation, and Support staff is trained to provide assistance.

 

Stay tuned!

 

Andrius.

I Have rhev-m 2.2 and rhev-h 5.7 How do i subscribe to the Z-Stream upgrade channel?

 

Thank you

Marcello

2.2 Z-stream updates are provided via RHN channels for the packages that are isntalled via RHN on RHEL hosts.

 

RHEV-Manager 2.2 is a windows installer package, and when an update is available, it can be downloaded from the RHN website. Run it on the current RHEV-M server, and it will kick off an upgrade.

 

RHEV-H also is a standalone package, the upgrade process for RHEV-H is described in the admin guide, but again, there is no yum there, and upgrades are done via the RHEV-M GUI.

 

In 3.0 RHEV-M is installed via RHN, so upgrades are possible without separate downloads (use rhevm-check-update to run the update properly). 

RHEV-H packages for 3.0 are supplied via RHN as well. But the procedure remains - you yum update rhev-hypervisor, and that downloads the rpm, installs it and unpacks the new ISO in the correct directory on RHEV-M. After that the upgrade procedure for the host is quite similar to the procedure for v2.2

Hi ,

 

When I bought into the rhev-h technology, I spoke with a System solution architect at redhat.

At that time the official release was the 2.2 .

I asked him what it would take to migrate from 2.2 to the 3.0 and he sais that the upgrade would be "seamless".

 

Now here I'm reading from Simon Grindberg post :

 

Next stage will be topgrade the hosts while moving them to a new cluster and then move the virtual machines to the new cluster.
Note: There will be a grace period in which working in the compatibility mode clusters is supported (You can even add more resources like hosts and storage to these clusters) though you won't be able to enjoy the enhanced features and performance benefits of the RHEL 6 based hypervizors. 

 

What doe it mean that there will be a grace period ... ecc ecc.. that if I want to take advantage of the new hypervisor features I have to create an entire brand new cluster and then migrate the vms there ?

It doesn't seem to seamless to me this migration.

 

And what about the SAN storage that I already have allocated do I have to duplicate the entire storage into the new one in order to transiction the vm from the old one??

 

Can somone explain to me?

 

Thank you

Marcello

Seamless here means you will be able to run your 2.2 hosts and VMs undet the 3.0 RHEV-M. When you're ready to move the VMs to new hosts, you set up a new host cluster, turn VM off, change the cluster in the VM properties, and start the VM. The outage in this case is minimal.

Note how I didn't say "new Data Centre" or "new Storage Domain". A DC can contain multiple clusters, the legacy one will remain 2.2, and the new one will be 3.0. Once you've moved all the VMs over, you can take the hosts away from the legacy cluster and remove it completely.

 

As for the hosts needing a reinstall - this is quite simple - you're moving from RHEL5 to RHEL6, there is no way of upgrading without a reinstall.

 

The final item is storage of course. You will not need to do anything with the storage, it will keep working as it has under 2.2.

RHEV 3.0 introsuced some improvements in terms of storage management and logistics. This removes or stretches some of the limitations that were present in the 2.2 storage design.

 

There is a tool being developed that converts v1 (older) storage domains to v2 (rhev3 and onwards) storage domains. You do not need to use the tool right away, but it will be recommended. The tool will edit the domain metadata and convert it to the new format, you will not need to move VMs over to a new storage domain (though that is also possible and supported)

Dan,

 

I want to thank you for your reply and also for claryfing some of the aspects about Migration.

 

I understand the all concept of data center and cluster, and I understand that I don't have to create a new data center for the migration.

 

My concerns are about the storage.

 

Let's assume that I will create a new cluster and I will migrate my vm's from the old cluster to the new one , this is seamless and I understand it because of the legacy between 3.0. and 2.2. But now in this scenario if I want to convert the storage to the 3.0 I have to run the tool you mentioned, in order to convert the storage domain to the 3.0 , the tool is not available yet right? How long it will take before it comes out?

 

Let's assume again that I don't want to have legacy storage and I want to go straight to the storage domain 3.0 and move my existing vms(2.2) to the new storage. Don't I have to create a new data center and cluster in order to attach the new 3.0 storage domain? And then, is it possible to migrate my vm from the old data center to the new one?

 

Thank you

Marcello

 

But now in this scenario if I want to convert the storage to the 3.0 I have to run the tool you mentioned, in order to convert the storage domain to the 3.0 , the tool is not available yet right?

 

The tool will be available soon. And you do not HAVE to run it, you can remain with the current domain format, and it will work.

 

 How long it will take before it comes out?

 

As soon as it's done with QE testing. Can't release a half-baked tool

 

Let's assume again that I don't want to have legacy storage and I want to go straight to the storage domain 3.0 and move my existing vms(2.2) to the new storage. Don't I have to create a new data center and cluster in order to attach the new 3.0 storage domain?

 

Absolutely not. More than a single storage domain can belong to a data center, same as more than a single cluster can belong to a data center

 

And then, is it possible to migrate my vm from the old data center to the new one?

 

Of course. To move a VM between clusters, just turn it off, and edit it's cluster property. It will start on the new cluster after that. To move a VM between storage domains, turn it off, right click, and select "Move". Will take a while, so be patient

Is this tool called rhev-migration-etl or part of this package?

 

Ok I don't have to create a new data center in order to have a new storage in the 3.0 domain, but, I need to allocate at least the same space that I had in the old one, which means that if I don't have this space available, my only option is to convert the existing 2.2 storage domain to the 3.0 once the migration tool is available.

 

In conclusion if I want to go 3.0 now without migrating the existing one, I have to create a new storage in the 3.0 , this precludes that I have other 40 TB available on my SAN storage which I don't have at the moment, then create a new cluster , in the same data center , shut off the existing vms , change the cluster property for the vms cluster and restart the vms .

 

Marcello

 

Greetings all,

 

Thank you for your patience while we worked to ensure a quality migration experience from RHEV-M 2.2 to 3.0.

 

The following are links to a few of the new documents created as part of the Migration Tool being pushed live to Red Hat Network:

 

Official Tech Brief: Migrating RHEV-M from 2.2 to 3.0:
http://red.ht/yZdtey

How are RHEV upgrades/migrations performed and supported?
https://access.redhat.com/kb/docs/DOC-64751

How do I upgrade the metadata for my storage domain from Version 1 to Version 2?
https://access.redhat.com/kb/docs/DOC-69911

 

Feel free to create a new Group discussion, or file a Red Hat Support case for further information.

 

Regards,

 

Andrius.

Red Hat, Inc.

Hello,

 

According to rhevm_2.2-3.0_upgrades.pdf from the "Official Tech Brief: Migrating RHEV-M from 2.2 to 3.0" article it is recommended to make shure that RHEV 2.2 upgraded to the latest version available.

How can I perform this upgrade? Just run the latest installer?

 

Kind regards,

Vladimir Pakhomov 

Download the latest RHEV-M 2.2 installer from RHN and run it. Make sure you have a valid backup of the currently running RHEV-M database first

Greetings Vladimir,

 

Help with upgrading a 2.2 installation to the latest 2.2.z can be found at the following article:

 

https://access.redhat.com/kb/docs/DOC-57194

 

Hope this helps!

 

Regards,

 

Andrius.

Red Hat, Inc.

This is a great news thank you for bring it to my attention.

I Will take a look to the links you sent it to me.

 

Marcello

The tech brief for migrating your RHEV-M 2.2 from Windows to a RHEV-M 3.0 in Linux (incorporating the new rhevm-migration tool) is described here:

 

https://access.redhat.com/knowledge/techbriefs/migrating-red-hat-enterprise-virtualization-manager-version-22-30

 

Keep in mind that this procedure is for installations that want their RHEV environment to continue without interruption. Hypervisors and storage are not upgraded in this procedure--only the RHEV-M is moved to RHEV 3.0. Hypervisors continue running as they are from the new RHEV-M in compatibility mode (RHEL 5.x) and storage (v1) is not upgraded to version 2 storage

we couldn't find out a way to upgrade the metadata for my storage domain from Version 1 to Version 2 without having a export storage domain. My issue is our storage domain altogether around 12 TB. To have a export domain we need to invest on another 12 TB of storage. We don't think it is ethical ask another 12TB for this migration only.

Hi Shantha,

 

First of all you need to understand that the metadata changes are not going to affect performance, and if you haven't run into any storage domain limitations, it should be safe enough for you to keep using the V1 version of metadata. 

Having said that, there is a tool that will automatically edit the metadata and update it to V2 being tested, and once it is verified to be ready for use, it will be released. 

 

So in short, you can simply keep on working using the old metadata model, with no effect on your VMs, and once the tool is ready, simply use it. Switching to the new metadata model is not a must.

Dan -

 

Will this tool remove the need to export the vms, upgrade the hosts and reimport them as described here - https://access.redhat.com/sites/default/files/rhevm_2.2-3.0_upgrades_01302012.pdf in the first section?

Let me try and explain the procedure itself. I hope it will make things more clear when I do.

 

First, what we do is upgrade the RHEV-M. RHEV-M 2.2 runs on Windows, and keeps its data in MSSQL. The first set of migration steps takes that data, packs it up, and then imports into a RHEV-M 3.0 setup, that uses Postgres. 

Once this is done, you will be able to see your setup using 3.0 management tools, but your hosts and storage will remain in legacy mode, which is supported in 3.0, with, of course, a more limited set of features. 

 

Once you see that everything is up and running, you will want better performance and features, and for that you need to move from RHEL5 based hypervisors to RHEL6 based hypervisors. That of course includes RHEV-H and RHEL.

 

As you probably know, upgrading RHEL5 to 6 is not supported, and that requires a reinstall. So this procedure still has to happen in offline mode - you take a host down into maintenance, remove it from RHEV-M, reinstall it with RHEL6/RHEV-H6, and add it, to a new, 3.0 compatible cluster. The old cluster, will of course be 2.2 compatible.

 

Any VM can be moved between clusters in the same datacenter, byt turning it off, editing the VM cluster affinity, and starting it again. This means some downtime for VMs, but the process can be taken gradually, one host and a few VMs at a time, and only when you're ready and have an outage window. 

 

Note that I haven't mentioned storage anywhere - you can keep using the V1 storage with the RHEL6 hosts in the 3.0 compatible cluster. It is recommended to upgrade the storage metadata, but again - it's not an absolute must, and can be done when you have a maintenance window, and when the tool has been released.

Hi Dan,

 

Can you please explain us more about this metadata upgrade.

Metadata is data that describes the properties of the storage domain. In the old format it contained some data that is no longer necessary with RHEV 3, so the tool will remove it, and reformat the data in a different way.

 

I don't think this is the place for deep technical dives into the actual code.

Any update on the metadata upgrade tool? We have migrated the manager and hosts to 3.0 compatibility but the storage domain is still V1 format. 

 

Do we have to shutdown the VMs to convert storage domains from V1 to V2 format or will this be a on the fly process?

I still don't have a date for the metadata update tool. As for the process itself, it will definitely be an offline process.

RHEV needs to support storage live migration. It is really painful to offline VMs to move them to a different storage domain. 

I am sure Dan didn't mean moving vms to different storage domains by sayng offline.

 

Offline migration means, you first shut down all guests, run the migration tool to convert existing storage domains from v1 to v2 and start the vms after that.

That is definitely a high priority feature currently under heavy development. 

Any update on the metadata update tool? We are still restricted to only 9 storage domains because of this. 

Updating to RHEV3.1 from 3.0 also updates the storage domain to V3. (Mentioned in RHEV 3.1 deep dive)

 

Are RHEV3.0 environments with V1 storage domains supported to migrate to RHEV3.1 with V3 converted storage domains?

Current plan is to upgrade from v2 to v3 when changing compatibility mode from Dc -> Edit -> compatibility mode from 3.0 to 3.1, obviously after all clusters are upgraded to 3.1 compatibility mode.

 

I need to check whether that will support upgrade from v1 to v3 directly after the 3.1 beta with the migration support is released.