Hello,

We have a pool with local storage, and when we perform updates we want to perform live migrations of all VMs on a particular host to a different host.

In XOA, we can display all VMs from a host, select them, and migrate them to a different host (within the same pool).
The issue here is that when we migrate multiple VMs at the same time, we notice a longer downtime in the last stage of the migration (I think it's the final pause before it moves over from old host to new host).
It goes a lot better when we migrate only 1 VM at a time.

For this reason, we'd like to set a custom concurrency when migrating multiple VMs.
I.e in this window we get when we select to Migrate:

An option to set concurrency to 1 would be very much appreciated so we can just select everything and the system will do its thing by itself one VM at a time.
Then a few hours later we can check and reboot the hypervisor when it is empty

Would something like that be possible?

Cheers!
Niels

@stormi Ah phew, good to hear we won't have to update everything so quickly again

Looks like yet another security patch from Xenserver available now

https://xenbits.xen.org/xsa/advisory-398.html

Thanks!

I see there's also another XSA available; XSA-396 (https://xenbits.xen.org/xsa/ )
Will these be combined with the microcode patches ?

Cheers!

Hi all,

Just bumping this to ensure it's not lost

Cheers!
Niels

Hello,

We have a pool with local storage, and when we perform updates we want to perform live migrations of all VMs on a particular host to a different host.

In XOA, we can display all VMs from a host, select them, and migrate them to a different host (within the same pool).
The issue here is that when we migrate multiple VMs at the same time, we notice a longer downtime in the last stage of the migration (I think it's the final pause before it moves over from old host to new host).
It goes a lot better when we migrate only 1 VM at a time.

For this reason, we'd like to set a custom concurrency when migrating multiple VMs.
I.e in this window we get when we select to Migrate:

An option to set concurrency to 1 would be very much appreciated so we can just select everything and the system will do its thing by itself one VM at a time.
Then a few hours later we can check and reboot the hypervisor when it is empty

Would something like that be possible?

Cheers!
Niels

@pdonias said in Request for wider modals:

Hi @NielsH, thanks for the feedback, we'll discuss it but this may indeed have to wait for XO 6.

No worries, glad it will come in XO 6 at least! Thanks!

@stormi said in Updates announcements and testing:

I theory, mirrorbits should always redirect you to a mirror that has the latest files you are requesting. However there's also a local cache for yum metadata. Try to clean it: yum clean all.

Ah yes, after that I see 22 packages. Just googling for this but appears to be based on the metadata_expire option in /etc/yum.conf. The man page says the default is 6 hours, but that config file has a commented out 90m. Either way, I'll wait a few hours/until tomorrow and then it should show all packages to update in XOA on all servers

@stormi said in Updates announcements and testing:

The long awaiting train of updates was finally published (including the XAPI update)!

https://xcp-ng.org/blog/2021/12/08/december-2021-xcp-ng-updates/

A big thanks for your feedback everyone, and get ready for the next ones!

Cheers!

We don't see them yet, but I assume it may take a few hours for the mirrors to update?

[13:59 xen32 ~]# yum  update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-base: mirrors.xcp-ng.org
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-updates: mirrors.xcp-ng.org
No packages marked for update

Hello,

In XOA, some of the modals are very narrow. i.e. the Migrate VM window looks like this:

Having this a bit wider would be very nice, for example like this (widened by changing the css):

Would it be possible to change the default size of these modals to be a bit wider?

@stormi said in Updates announcements and testing:

The updates I wanted to group them with did not come, so it all got delayed (and retrospectively I could have released them earlier).

Are you waiting for a specific fix?

Not specifically, but we have not yet installed the previous patches. We were planning on combining them with the upcoming patches. Since it always takes a while to update / reboot all hypervisors we wanted to avoid double work if we were to install the current available updates today and for example tomorrow new ones are released