Le vendredi 22 novembre 2024, 18:48:47 CET Sean Mooney a écrit :
On 22/11/2024 12:31, Gilles Mocellin wrote: [...]
Yes, this is the case, but I thought live_migration_permit_auto_converge would solve that. And the other problem is the libvirt stacktrace when I force the completion...
in generall live_migration_permit_auto_convergewhil it can help is much less effective the
live_migration_permit_post_copy
i dont know if your are using 1G hugepages?
I don't think, except if it's default with OpenStack-Ansible on Ubuntu... I will check.
live migration is almost impostible with 1G hugepages without post_copy because wrting a single
bit a 1G page requried the entire 1G page to be transfered again.
post_copy make all the write go to the dest instance after an inital memroy copy
and pagefaults reads across the network as pages are needed while it copys them in the backround.
I've read about post copy, but it seems to much risky, we can really loose data if the source vM crash, and destination hasn't caught up.
auto converge just add micro pauses to briefly stop the guest cpu cores to allow migration to make progress. in other words auto converage is hoping that if we slow the cpu execution enough the migration will eventually complete but it can actully guarentee it will ever complete.
OK, no guaranty.
2. Not sure since it's using Linux bridge agent which has been moved to experimental, you probably want to schedule migrating away from using it. Look into the enable_qemu_monitor_announce_self in nova.conf so that nova in post-migration does an QEMU announce_self that sends out RARP frames after the migration is complete if there is a race condition between the RARP frames being sent out and the port being bound, which is the case for us when using OVS agent.
Mmm, that's interesting. I didn't see that parameter. I'm trying to have a reproducible test and will try enable_qemu_monitor_announce_self. I'll come back here if I have a clear answer.
enable_qemu_monitor_announce_self is a workaroudn option in nova
it shoudl work with linux bridge too however i dont think its required when using linux bridge becasue configure are no openflow rules ectra to configre, it wont hurt however so its worht enabling if you are having downtime issues.
No Openflows, but iptables rules for security groups...
by the way you ask about `nova host-evacuate-live` and osc. that command is a clinet only implementation that we don't intend to ever port. we do not support it any more. it was deprecated when the nova-client cli was deprecated and it will be removed when python novaclinet deliverable removed.
its effectively just a for loop over a server list for a given host with no error handling operators should not use it or build tooling around it. the same applies for the non live version
it should not be used.
Oh, that's sad. It's really a must have command for any OPS, especially those who came from Vmware vSphere. And it should even be in Horizon (in fact, it is ! But probably also a loop in horizon...). Ceph added a maintenance mode for nodes, that's really something needed for any hardware, firmware or OS update in any clusters. Kunernetes also has a way with cordon / drain nodes. Thanks Sean, PS: Sorry for the rant, but : If we want OpenStack to be a serious alternative for VMware refugees and also to survive the rise of KubeVirt, it should really have a dynamic scheduler like Kubernetes, to allow : - Maintenance mode (live evacuation) - HA (auto restart instance when a hypervisor crash) - "DRS" (Redistribute instances to spread evenly the load on every nodes. Yes, Watcher is resurrected and can do that, but is really not dynamic) For all of that, live migration should be rock solid. And I don't talk about integrated backup and monitoring. End of Rant, sorry again. -- Gilles