We started with the pool master using the ISO install method as the yum upgrade method failed on a test stand alone system but succeeded with the ISO method.

Upgrade process went smoothly with no downtime experienced with any VMs. We have a mixed environment of windows 2k12 and linux variants as guests.

After the final machine was upgraded (and latest patches applied via yum update and host restart) we started running into problems. Hopefully this will help someone avoid these problems:

1. We noted that the new microcode flagged a "new cpu features enabled" notice in xcp-ng center. We thought that was odd, since the side channel mitigations cripple cpus, not enhance them. I think this in retrospect changed the "mask".
2. Migration of some but not all windows vms after upgrade and patch ran into problems. migration would hang and never complete. It required a shutdown from the console and a toolstack restart to regain hypervisor level control of the hung migrating vm. We managed to move the hung vms in shutdown state.
3. Moving LINUX vms after the upgrade caused some to hang in the same manner - one of them even crashed and would not restart. After 2 toolstack restarts we managed to restart this critical VM.
4. I noted a post from Tobias over on the citirx xenserver forum that advised that since the microcode for the new foreshadow vulnerability changes the cpu mask, a shutdown and restart of the VM is necessary to regain VM agility. I'm hopeful this will solve the migration issues (and kernel updates on the linux vms).

Bottom line - in our environment we believe it is required to shutdown and restart each vm in order to regain reliable agility to move between hosts a running vm. We can't really test this fully until we have a maintenance window scheduled.

Understood. I think serious consideration should be given to running the LTSR as well as the CR. If xcp wants to attract larger organizations (we are small but still like stability over features) the LTSR track is the way to go. Perhaps when we get to xenserver 8.x there will be another LTSR that could be considered.

I for one wish xcp-ng had a LTSR track. This pace is overwhelming. Constant upgrades of critical infrastructure is not my idea of "fun".

Hi Stormi - any chance you could add support for Gentoo Linux?

@stormi, would you please let us know what the impact is of the removed packages?

What functions are lost by not having xapi-clusterd?
What functions are lost by not having sm-transport-lib?
What functions are lost by not having xapi-storage-plugins?
What functions are lost by not having livepatch-utils?

Also - it seems apparent that Citrix is making every effort to close source the project. Are there any attorney types on the list that understand the licensing requirements of LGPL? I'm not expert on this at all - but the official "gpl" page seems to indicate that once distributed, it is open. https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic

Understood. I think serious consideration should be given to running the LTSR as well as the CR. If xcp wants to attract larger organizations (we are small but still like stability over features) the LTSR track is the way to go. Perhaps when we get to xenserver 8.x there will be another LTSR that could be considered.

I for one wish xcp-ng had a LTSR track. This pace is overwhelming. Constant upgrades of critical infrastructure is not my idea of "fun".

We started with the pool master using the ISO install method as the yum upgrade method failed on a test stand alone system but succeeded with the ISO method.

Upgrade process went smoothly with no downtime experienced with any VMs. We have a mixed environment of windows 2k12 and linux variants as guests.

After the final machine was upgraded (and latest patches applied via yum update and host restart) we started running into problems. Hopefully this will help someone avoid these problems:

1. We noted that the new microcode flagged a "new cpu features enabled" notice in xcp-ng center. We thought that was odd, since the side channel mitigations cripple cpus, not enhance them. I think this in retrospect changed the "mask".
2. Migration of some but not all windows vms after upgrade and patch ran into problems. migration would hang and never complete. It required a shutdown from the console and a toolstack restart to regain hypervisor level control of the hung migrating vm. We managed to move the hung vms in shutdown state.
3. Moving LINUX vms after the upgrade caused some to hang in the same manner - one of them even crashed and would not restart. After 2 toolstack restarts we managed to restart this critical VM.
4. I noted a post from Tobias over on the citirx xenserver forum that advised that since the microcode for the new foreshadow vulnerability changes the cpu mask, a shutdown and restart of the VM is necessary to regain VM agility. I'm hopeful this will solve the migration issues (and kernel updates on the linux vms).

Bottom line - in our environment we believe it is required to shutdown and restart each vm in order to regain reliable agility to move between hosts a running vm. We can't really test this fully until we have a maintenance window scheduled.