[GitHub] [cloudstack] ravening commented on issue #3610: [WIP DO NOT MERGE] KVM: Rolling maintenance
ravening commented on issue #3610: [WIP DO NOT MERGE] KVM: Rolling maintenance URL: https://github.com/apache/cloudstack/pull/3610#issuecomment-574208972 > This requires VM-per-VM tracking/migration effort and is way outside of the scope of this work/PR. It is however an interesting idea for some future improvements. Yes of course this is not good to implement within cloudstack itself. That's why we have a separate application to do that where we are using the above algorithm This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [cloudstack] ravening commented on issue #3610: [WIP DO NOT MERGE] KVM: Rolling maintenance
ravening commented on issue #3610: [WIP DO NOT MERGE] KVM: Rolling maintenance URL: https://github.com/apache/cloudstack/pull/3610#issuecomment-574160585 > > This is any day better than rolling upgrade wherein worst case a VM can be migrated n-1 number of times. > > that would mean there is either space for all vms on all hypervisors, or that only one vm is present in the whole environment, so that is an unlikely case, but I do see your point. > Any algorithmic changes to suggest, @ravening ? One thing I suggest to avoid running enableMaintenancemode api on all hypervisors to upgrade it. Instead run enableMaintenanceMode on first hypervisor which will migrate away the VM's. Upgrade it. Now from second hypervisors onwards, run findHostForMigration for each vm and see if the list contains the upgraded hypervisor. If so then migrate the vm to the upgraded hypervisor. This way you can prevent multiple vm migrations This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [cloudstack] ravening commented on issue #3610: [WIP DO NOT MERGE] KVM: Rolling maintenance
ravening commented on issue #3610: [WIP DO NOT MERGE] KVM: Rolling maintenance URL: https://github.com/apache/cloudstack/pull/3610#issuecomment-573864393 > ... > > > We have a similar application to perform all these tasks and also a centralized dashboard to control upgrading hypervisors on all platforms in a different locations. > > @ravening do you have this in public domain somewhere? > We use this application in our company to upgrade all hypervisors in our platform. Its not public yet. > > Update: > > Nvm, I went through the code and understood what its doing. It enables maintenance mode on each individual hypervisor. This can be really bad in most cases because in the worst case a VM can be migrated multiple times > > @ravening I cna safely say that at least all the VMs from the first host to be handled will be migrated multiple times. How is this bad? And how could this be avoided? @DaanHoogland In the worst case, a VM will be migrated twice. Once from the first hypervisor on which we start the upgrade to any random hypervisor and secondly from the hypervisor where it is already migrated to the upgraded hypervisor. This is any day better than rolling upgrade wherein worst case a VM can be migrated n-1 number of times. Im using findHostsForMigration to find a suitable host for migration which is already upgraded to migrate the vm. In this PR, the upgrade algo uses enableMaintenance command which can migrate VM to any non upgraded hypervisor. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
