cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <>
Subject RE: [cloudstack-devel] Hyper-V Support
Date Sat, 21 Apr 2012 21:15:30 GMT

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


-----Original Message-----
From: Alessandro Pilotti [] 
Sent: Saturday, April 21, 2012 11:05 AM
Subject: Re: [cloudstack-devel] Hyper-V Support


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

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

View raw message