Jump to content
Welcome to our new Citrix community!
  • 0

Upgrade a pool from 7.0 to 7.1 LTSR. Or would it be better to 7.6?


Anderson Alipio Costa

Question

Hello all,
 

I've been looking for a few days, a solution to my situation, but nothing like my case solved yet, so here it goes...
 

Here is my current scenario, we have a pool with 2 servers running on XenServer 7.0, they have local storage each and no shared storage, except a NFS for ISO and bkp purpose only. They are running today with over 80% of their capacity.
 

It became nescessary to upgrade them to use a new software that can only be used in a 7.1 or later, and also add a new server in the proccess.

 

The new server has arrived, we are now planning the upgrade proccess and I've got stuck in some questions, such as:
 

Can I install the new version on the new server, add it to the pool (witch already have a master but running on a 7.0, just saying that, because I read that the first to be upgraded should be the master), or I should install the 7.0 to the new server, migrate the VMs to it from each server at a time and so on?
 

Another question is, I've also read that the live migration of VMs from a host to another using differente storage (in my case, at least for now, using the host's local storage) is no longer allowed in free editions, only if they share the same storage. If so, does that also apply to the 7.1 LTSR or just from 7.2 and newer?
 

And finaly, which is recomended, 7.1 LTSR or 7.6 free edition? We are a small company with limited resources, but will be using standard version soon, but can't afford it just yet.
 

Dumb question, can I use the latest XenCenter interface such as 7.1 or 7.6 with a pool that have 7.0 servers?
 

Sorry for the long text, tried to be the most clear as possible with some details, as I found several questions like mine without some solution seen that is a little different than the usual.
 

Thankyou so much in advance.
 

Best Regards,
 

Anderson Alipio

Link to comment

15 answers to this question

Recommended Posts

  • 0

Hello Anderson,

 

Here are the answers to your questions:

 

Can I install the new version on the new server, add it to the pool (witch already have a master but running on a 7.0, just saying that, because I read that the first to be upgraded should be the master), or I should install the 7.0 to the new server, migrate the VMs to it from each server at a time and so on?

 

Suggested steps:

 

Note: Prior to performing the steps outlined below, please confirm the new server (hardware) is compatible with the two existing servers and that all three servers are compatible with the latest version of the Citrix Hypervisor software: http://hcl.xenserver.org

 

1. Install the latest version on the new server and then join it to the existing pool and make it the pool master.

2. Migrate the VMs on one of the two existing servers to the new pool master and upgrade that server to the latest version.

3. Migrate the VMs on the remaining existing server to the other server upgraded in step 2 and upgrade the remaining existing server to the latest version.

4. With all three servers running the latest version, migrate VMs across all three servers to balance the load.

 

Another question is, I've also read that the live migration of VMs from a host to another using differente storage (in my case, at least for now, using the host's local storage) is no longer allowed in free editions, only if they share the same storage. If so, does that also apply to the 7.1 LTSR or just from 7.2 and newer?

 

Applies from 7.2, up to and including the latest release - 8.0.

 

And finaly, which is recomended, 7.1 LTSR or 7.6 free edition? We are a small company with limited resources, but will be using standard version soon, but can't afford it just yet.

 

If 7.1 LTSR (Long Term Service Release) provides your environment with the features it needs for now and the foreseeable future and you do not want to upgrade frequently (i.e., every six months or so), than 7.1 would probably be best-suited for you at this time. If however, you are interested in obtaining the newest features as they are released and are able to upgrade more frequently, than a Current Release (CR) would probably make the most sense for you. As 7.6 CR will soon be out of support (for Citrix Success customers), we'd recommend going with 8.0 CR for new or upgraded installations.

 

Dumb question, can I use the latest XenCenter interface such as 7.1 or 7.6 with a pool that have 7.0 servers?

 

While you can use a newer version of XenCenter to manage older versions of XenServer, we recommend upgrading your XenServer (Citrix Hypervisor) environment at your earliest convenience in order to leverage the newest features.

 

Thank you,

Andy

Citrix Hypervisor PM

 

Link to comment
  • 0

Thank you so muth Andy! It was just what I needed!

 

One last thing, as you said that XenCenter can be used in the newer version. But wich is better in my case as I'm going to use 7.1 LTRS im my servers, use the same XenCenter 7.1 or could I use the XenCenter 7.6 with the XenServers at 7.1?

 

Thanks again!

 

Best regards,
Anderson Alipio

 

Link to comment
  • 0
2 hours ago, Andy Melmed1709155373 said:

Anderson,

 

In addition to the information Alan provided, please note that while you could manage a 7.1 environment with XC 7.6, you would not have access to any of the features introduced between 7.2 CR and 7.6 CR, so there would be no real advantage to managing a 7.1 environment with XC 7.6.

 

Andy

 

 

... other than if you wanted to also use an even newer release of XC (like 8.0) to access some development XS hosts/pools.  I run XC 8.0 as I have a collection of 7.1 LTSR, 7.6 and 8.0 pools to manage.

 

-=Tobias

Link to comment
  • 0

My 7.0 pool runs the 911 CAD software so getting any time for upgrade is just a nightmare. Upgrading the pool 

just about has to coincide with the yearly software upgrades they go through. I know you get it on having a 

short window to get stuff done. 

 

--Alan--

 

Link to comment
  • 0

Anderson,

 

After conferring with several of my colleagues, it was agreed the most effective approach to adding a new server while simultaneously upgrading your existing XS environment would be as follows:

 

1. Install 7.0 on the new server and add it to the existing 7.0 pool.

2. With all three 7.0 hosts running in the pool, launch XenCenter 7.1 and run the Upgrade Wizard, which will automatically migrate VMs across hosts as each host is upgraded to 7.1.

3. Once all hosts have been upgraded to 7.1, continue to use either XC 7.1 or XC 8.0 to manage the 7.1 XS environment.

 

The above would be the preferable approach to introducing a new server into the existing pool and upgrading the entire pool from 7.0 to 7.1.

 

Andy

 

Link to comment
  • 0

Anderson,

I'm curious if the servers are Intel or AMD-based? I've run into issues with AMD-based hosts in particular that an upgrade changes the CPU mask and hence feature set such that automatic migrations of VMs to other hosts fail during the upgrade process because the host now is considered to be not fully compatible. The saving grace is that you can still force the VMs to migrate using the "xe vm-migrate" command together with the "--force" option. I've had to do this a few times when encountering this issue. You can then restart or resume the upgrade process, as needed.

 

-=Tobias

Link to comment
  • 0
On 21/06/2019 at 1:57 PM, Andy Melmed1709155373 said:

Anderson,

 

After conferring with several of my colleagues, it was agreed the most effective approach to adding a new server while simultaneously upgrading your existing XS environment would be as follows:

 

1. Install 7.0 on the new server and add it to the existing 7.0 pool.

2. With all three 7.0 hosts running in the pool, launch XenCenter 7.1 and run the Upgrade Wizard, which will automatically migrate VMs across hosts as each host is upgraded to 7.1.

3. Once all hosts have been upgraded to 7.1, continue to use either XC 7.1 or XC 8.0 to manage the 7.1 XS environment.

 

The above would be the preferable approach to introducing a new server into the existing pool and upgrading the entire pool from 7.0 to 7.1.

 

Andy

 


Thanks Andy, I'll try it, but does that apply to separate storage such as local storage in the servers? Will it migrate automatically even if the storage are different?


 

Link to comment
  • 0
On 21/06/2019 at 4:38 PM, Tobias Kreidl said:

Anderson,

I'm curious if the servers are Intel or AMD-based? I've run into issues with AMD-based hosts in particular that an upgrade changes the CPU mask and hence feature set such that automatic migrations of VMs to other hosts fail during the upgrade process because the host now is considered to be not fully compatible. The saving grace is that you can still force the VMs to migrate using the "xe vm-migrate" command together with the "--force" option. I've had to do this a few times when encountering this issue. You can then restart or resume the upgrade process, as needed.

 

-=Tobias

Tobias, they are all Intel, two of them Dell T430 with Xeon E5-2630 v3 and the new one a Dell R440 with Xeon Silver 4112

 

Anderson.

Link to comment
  • 0

Hi,

 

It's been a while, but only now I've found a windows to upgrade, and at the begginnhing it all seams ok, but when trying to migrate online VM's from old slave server to the upgraded master it gives me this error message:

 

Performing a Storage XenMotion migration. Your VM's VDIs will be migrated with the VM.
Will migrate to remote host: srv-vm01, using remote network: Pool-wide network associated with eth0. Here is the VDI mapping:
VDI 75400759-8829-48a0-b4ee-d8dd56a0facc -> SR 652efd1c-e37e-2f33-4ed3-3deffb251ed6
You tried to call a method with the incorrect number of parameters. The fully-qualified method name that you used, and the number of received and expected parameters are returned.
method: VM.migrate_send
expected: 6
received: 7

 

I've tryed by the interface and also by command line (xe vm-migrate remote-master=x.x.x.x remote-username=root remote-password=xxxxxx vm=VM_NAME host=srv-vm01 live=true vdi:75400759-8829-48a0-b4ee-d8dd56a0facc=652efd1c-e37e-2f33-4ed3-3deffb251ed6) and the result was the same.

 

The VM's that are down can be moved, but online ones cannot be live migrated.

 

Did anyone seen this error before? Can it be fixed? 

 

Thankyou all.

 

Anderson.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...