Alessandro, Your points make a lot of sense, orchestrating with yet another external management server like SCVMM and vCenter is a lot complex than orchestrating host directly.
With agent mode (orchestrating host directly), the next question you might want to answer is to how to deploy and automatically upgrade agent to hyper-V hosts, majority of CloudStack management server deployments are running on non-Microsoft systems. We use SSH based approach to deploy KVM agent and XS plugin, not sure if there is any WMI based java implementation available to help finish the job to remotely push agent software from management server to Hyper-V host, this can greatly improve the user experience. If not so, it may be worth to develop a WMI/PowerShell broker service to help orchestrate Hyper-V host natively in WMI or Powershell from CloudStack. Although it is still a valid option to just follow existing CloudStack java agent approach, let the java agent take CloudStack management server JSON commands which in turn to call native WMI/PowerShell on Hyper-V host, I'm wondering that if you already have a PowerShell/WMI repo of hyper-V orchestrating building blocks, a PowerShell/WMI broker in this situation might be a better option. With this option, you may launch a agent-proxy inside CloudStack management server, and remotely run native PowerShell natively via the broker service (similar to remote SSH). Kelven -----Original Message----- From: Alessandro Pilotti [mailto:[email protected]] Sent: Saturday, April 21, 2012 11:05 AM To: [email protected] Cc: [email protected] Subject: Re: [cloudstack-devel] Hyper-V Support Hi, we also thought about SCVMM integration vs direct management of the hosts when we started developing our management solution. We decided against it in our scenario for the following reasons: SCVMM does not provide significant features that the hosts cannot provide directly SCVMM is definitily not a free product SCVMM introduces additional architectural requirements and complexities SCVMM overlaps with CS in a lot of areas The only reason where it might be useful to provide integration with SCVMM is for customers that want to run CS on top of an existing SCVMM infrastructure. This means that we'd also like to provide adapters for this scenario at a later stage, which is not a problem as SCVMM provides a rich PowerSell set of APIs that we can wrap. Your architectural parallel between SCVMM and vSphere is correct, with the difference that the fault tolerant features (e.g Live Migration) are handled by the operating system itself, not by SCVMM (we already support them in our framework). In VMWare case, those features (vMotion etc) are handled by vSphere not by ESX/ESXi. Let me know what do you guys think about it! Alessandro Pilotti MVP ASP.Net / IIS On Apr 21, 2012, at 05:52 , Kevin Kluge wrote: > Alessandro, one other question -- can you explain the rationale for managing > Hyper-V directly, as opposed to going through SCVMM? CloudStack's VMware > integration goes through vCenter. We chose that model since we heard from > users that VMware administrators liked using vCenter as a management point. > Also, there are some features that are implemented by vCenter that a > direct-host management integration could not provide without re-implementing > similar functionality itself. I had assumed that a Hyper V integration would > have similar issues , suggesting management via SCVMM would be advantageous, > but I am relatively less familiar with Hyper-V technology and administrator > preferences. Thoughts? Are there any features that we "lose" by going > direct to host versus through SCVMM? > > -kevin
