I have a PR for this if someone can please verify...? On Tue, Jun 16, 2015 at 3:30 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > nobody has been taking this up. In order to have a 4.4.4 I will go for > the quick hack (in 4.4 and 4.5) > > On Fri, Jun 5, 2015 at 9:29 AM, Koushik Das <koushik....@citrix.com> wrote: >> From the persistent config changes, it appears that aggregate command >> approach is not required in 4.6 and onwards. If someone wants to implement >> the aggregate approach only for 4.4 and 4.5 irrespective of the effort >> involved then that should be fine. >> >> Otherwise we can just put some config to decide between #1 or #2. Another >> alternate could be to replace the reboot logic with an alert if there is an >> out of band VR migration. Based on it admin can reboot the VR from CCP if >> required. There will be a window during which the VR will be without ant >> config but that can be documented. >> >> -----Original Message----- >> From: Remi Bergsma [mailto:rberg...@schubergphilis.com] >> Sent: Thursday, 4 June 2015 19:56 >> To: dev@cloudstack.apache.org >> Subject: Re: [DISCUSS] Out of Band VR migration, should we reboot VR or not? >> >> +1 >> >> On 04 Jun 2015, at 14:29, Rohit Yadav >> <rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>> wrote: >> >> Hi, >> >> On 04-Jun-2015, at 11:05 am, Remi Bergsma >> <rberg...@schubergphilis.com<mailto:rberg...@schubergphilis.com>> wrote: >> >> To summarise: >> #1. rebooting VR is needed for hypervisors that have their own DR (like >> VMware and Hyperv) as a restart outside of CloudStack makes it lose its >> config hence the VR is unavailable #2. rebooting is NOT needed for >> successful live migrations on _any_ hypervisor (since there was no restart >> everything still works) #3. CloudStack 4.6 has persistent config in VR, so >> rebooting is never needed >> >> The current behaviour in 4.4.3, 4.5.1 and master: >> - always rebooting VR when out-of-band detected ==> Works great for #1, but >> makes case #2 not work >> >> The previous behaviour: >> - never rebooting VR when out-of-band detected ==> Works great for #2, but >> makes case #1 not work >> >> We need something that works for both cases :-) >> >> About #1 and #2: >> Can we detect in another way that a VR became unreachable/non-functional and >> do an action based on that? >> >> So, if a VR lives on a VMware hypervisor that happens to crash, VMware HA >> will start it on another available hypervisor but without config it will not >> be reachable on the control network. If we want to do it generic, I’d say >> that when a VR is not controllable any more we could reboot it. We could >> also make this a setting ‘systemvm auto reboot on control failure’ or >> whatever we call it. >> >> This would then also be a useful feature in 4.6 >> >> About #3: >> I’d suggest at least reverting the commit to master, as it makes no sense >> since the VR is persistent already. >> https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java#L2638 >> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=c3515c9 >> >> I agree on master, we can revert due to #3. >> >> On 4.4 and 4.5 branches, if we revert it than it will break #1 and if we >> keep it - it breaks #2. We need to fix this in a hypervisor agnostic way. >> >> So, if we can use aggregated cmd execution that Sudhashu and others have >> shared, in case of an out of band migration we can do this: >> >> 1. If we’re unable to reach VR, we can keep the RebootTask to do its job. In >> many cases I’ve seen VR disk corruption, so if after rebooting VR (which >> might kick in fsck) it fails CloudStack may eventually recreate a new VR >> makes sense. This will solve #1. This case IMO is highly unlikely. >> >> 2. If we’re able to reach the VR after VR is migrated out of band, we run an >> AgrregationExecutionTask sending all the rules for that VR. This will solve >> #2 without needing to reboot a VM. This case is more likely to happen, so if >> I’ve pick between this and the above case, I would try to solve for this >> case. >> >> I’m not sure about the actual implementation, and will re-applying rules >> using a AgrregationExecutionTask cause any issue in the VR? Comments? >> >> Regards, >> Rohit Yadav >> Software Architect, ShapeBlue >> M. +91 88 262 30892 | >> rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com> >> Blog: bhaisaab.org<http://bhaisaab.org/> | Twitter: @_bhaisaab >> >> >> >> Find out more about ShapeBlue and our range of CloudStack related services >> >> IaaS Cloud Design & >> Build<http://secure-web.cisco.com/11NRz12My3B5Kzq2aGFKO015q6rxTtLhqlUFP7QMrC0-v_oGzAZzQRov3cOzFQSsoQWiiSpaXHXNHsmfncQDtL7aKrU44zCUAb42UC_t2RaRK1rZc7LdKyQRujP_oVBG8novKP65vr7lykJvafQToJSMcAFzzj2JUV9jZ6Lci-_snpKPxRE6vFwzL_Pi9BksK/http%3A%2F%2Fshapeblue.com%2Fiaas-cloud-design-and-build%2F%2F> >> CSForge – rapid IaaS deployment >> framework<http://secure-web.cisco.com/1zDH16MEoBBXO2Aec7JxxfmsbN0-qdNbRkKTaQgb3gu3jOOXzW-4p6XKmZbRcvF5SE5njzz8vnF5PnPQIa_rsd5pUFtuDIx5ldguqoBt4Rk2nhHc6mwB2vtbzN4A9x-8vj7qn0ySYXnUC6gqnft-HDDQowNC3KHSq-CoU7bqHsNG3C5JRrNl1eCvNgVnudnbO/http%3A%2F%2Fshapeblue.com%2Fcsforge%2F> >> CloudStack >> Consulting<http://secure-web.cisco.com/1-OtYLlvNuHbvbTUwsXuMO3DwRAlWKunbc3M6Q33mljUFXCuyzHK2fBYu0AFTyWepJ92k1NEHyCBTsbPRppXOC6QTmwwePInVQQCg0U6-WvvydOsE_gcyNG28N4NPoBdUZPVgJqZgKptvXAacDyAIHrv1QQxSxMUY36UNVXZAhSXsXock3Opz1pelR-9LBmm-/http%3A%2F%2Fshapeblue.com%2Fcloudstack-consultancy%2F> >> CloudStack Software >> Engineering<http://secure-web.cisco.com/1eOOKbuGnQ5GwXa19eDF6ksRMZX5ph-7BozqOFbRiImEuer_HG6IBDJVlGyGcbGZdrCnHhvJFDp-Yl0L1eB-XbPf50nZMe2WOGKYSsx2mk-zuEuPNFwRiF0MEVRv4oOIznqqVe3tVXJwhdFfj9DYzq-7pBCplAeljApsG9e1yH0KfjpwzYN1pIX77I6NWMy1W/http%3A%2F%2Fshapeblue.com%2Fcloudstack-software-engineering%2F> >> CloudStack Infrastructure >> Support<http://secure-web.cisco.com/1LjFiZT2WK_5OIqPsi82bcmnjV9p4bsGMz2bLnslp-tPxyh7oZ_rhhm3B0RkTE-7NVtbttV-kUxjPISzjpcwwsDcVpsdkC-CmrieRvQCvZj_8N_xmpmMcX32VE8-I2wSlfUACTy62VSNNtFDHiTY-g299bPGmj1DA1NxiAV7a2iDV31hfpZ84s_Q2GkQeeoeC/http%3A%2F%2Fshapeblue.com%2Fcloudstack-infrastructure-support%2F> >> CloudStack Bootcamp Training >> Courses<http://secure-web.cisco.com/1GLYfy58uh9y-GuJdHLdpEruL8xIozImvUMGAxmjXtZvGSslV1DM4CdYTvSdbh2ci1Zor1wY5_Ibsq6Wb4RXrEKV9nuZhTWALVGYyDfuWtDBgjzFEgNx64DrghuaQa04hs2-VkbPFjnmBvQr2OsLG_YbLZHOsv7NLBqmwNq7YjEXEbIHvPvrLB4eMTyt4pfrg/http%3A%2F%2Fshapeblue.com%2Fcloudstack-training%2F> >> >> This email and any attachments to it may be confidential and are intended >> solely for the use of the individual to whom it is addressed. Any views or >> opinions expressed are solely those of the author and do not necessarily >> represent those of Shape Blue Ltd or related companies. If you are not the >> intended recipient of this email, you must neither take any action based >> upon its contents, nor copy or show it to anyone. Please contact the sender >> if you believe you have received this email in error. Shape Blue Ltd is a >> company incorporated in England & Wales. ShapeBlue Services India LLP is a >> company incorporated in India and is operated under license from Shape Blue >> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil >> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a >> company registered by The Republic of South Africa and is traded under >> license from Shape Blue Ltd. ShapeBlue is a registered trademark. >> > > > > -- > Daan
-- Daan
