The procedure for upgrading a self-hosted Red Hat Virtualization environment, including host updates, must be documented. Assignee to work with QE to determine workflows, prerequisites, and known issues.
Correcting target for GA.
Accepting into the GA program and assigning to Emma for review. I'm bumping up the estimate by a couple of hours to account for any investigation required for the extra points that have been added to this bug since the initial estimate was made.
Adding dependency on repository update BZs for GA. The same repo information can be used in the upgrade procedures.
Hi Simone Can you update me about the status of this procedure. 1. Is it ready to be documented? 2. Is there and RFE? 3. Have you documented the procedure? Thanks!
Nothing special here: 1. set HE global maintenance mode 2. upgrade the engine from 4.1 to 4.2 3. exit global maintenance mode 4. upgrade the hosts as usual
(In reply to Simone Tiraboschi from comment #8) > Nothing special here: > > 1. set HE global maintenance mode > 2. upgrade the engine from 4.1 to 4.2 > 3. exit global maintenance mode > 4. upgrade the hosts as usual Simone, what about customers with 3.6 or 4 what is the procedure? For example, the procedure from 3.6 to 4.1 was to "sequentially upgrade to any later versions of Red Hat Virtualization before upgrading to the latest version. For example, if you are using Red Hat Enterprise Virtualization 3.6, you must upgrade to the latest minor version of Red Hat Virtualization 4.0 before you can upgrade to Red Hat Virtualization 4.1." So should customers with either 3.6 first upgrade to 4.0 and then to 4.1 latest version and only then to 4.2? Should 4.0 customers first upgrade to 4.1 lastest minor version and then to 4.2?
Hi Simone, In addition to the previous question, does */var/tmp* directory still require 5 GB in which to extract the appliance files? Thanks!
(In reply to Emma Heftman from comment #9) > Simone, what about customers with 3.6 or 4 what is the procedure? We cannot skip versions on engine side so as a general rule: 3.6 -> 4.0 -> 4.1 -> 4.2 3.6/el6 -> 4.0/el7 requires a special procedure due to the el6 -> el7. 4.1 -> 4.2 it's exactly as 4.0 -> 4.1 > For example, the procedure from 3.6 to 4.1 was to > "sequentially upgrade to any later versions of Red Hat Virtualization before > upgrading to the latest version. For example, if you are using Red Hat > Enterprise Virtualization 3.6, you must upgrade to the latest minor version > of Red Hat Virtualization 4.0 before you can upgrade to Red Hat > Virtualization 4.1." > > So should customers with either 3.6 first upgrade to 4.0 and then to 4.1 > latest version and only then to 4.2? Yes, exactly > Should 4.0 customers first upgrade to 4.1 lastest minor version and then to > 4.2? Yes, right
(In reply to Emma Heftman from comment #10) > Hi Simone, > In addition to the previous question, does */var/tmp* directory still > require 5 GB in which to extract the appliance files? > > Thanks! Just for 3.6/el6 -> 4.0/el7 upgrades. It's not required for 4.0 -> 4.1 or 4.1 -> 4.2
Progress: Worked on all upgrade paths with Simone. 3.6> 4.2 4.0 > 4.2 4.1 > 4.2
Yaniv/Sandro/Pavel Can you confirm whether we have any SHE customers with remote databases? Is this scenario something that is being tested by QE? This RFE doesn't specifically mention it, but it may have slipped through. Thanks! Emma