Doug S (foo.delete@this.bar.bar) on October 17, 2021 1:33 pm wrote:
> me (me.delete@this.me.com) on October 17, 2021 12:31 pm wrote:
> > > But not always practical. If you have only one cluster at a certain site or dedicated to a certain
> > > application suite / function, you would have to expand with models containing older CPUs instead
> > > of getting newer/better ones, need to replace everything when you upgrade, etc.
> > >
> >
> > If the downtime of shutting down a VM, migrating to a new cluster and starting
> > it back up is unfeasible... you're probably not upgrading unless you have to.
>
>
> Upgrades can use live migration. Everything is pretty well automated (though you can manage it manually
> if desired) so you can install new servers, add them to the cluster, and some of the running VMs
> will soon be automatically and transparently migrated to them to balance the overall load.

Upgrades are easy using live migration, unless new hardware removes a function. If you guarantee that the upgraded hardware supports everything the old hardware did the VMs should migrate without a problem. The problem becomes when you start a VM on the upgraded hardware but want to migrate it back to the older hardware. There a new feature may have been used that the old hardware doesn't have.

Speaking as someone who works a lot on defining new functions on IBM Z and having to deal with the complications of live migration, it is not a simple problem to deal with unless the application is aware something can change underneath. If every application checked proper CPU feature bits before using functions it would be easier, than the ones that do things like try an instruction and handle the interrupt if there is an illegal instruction.