cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: [DISCUSS] RESTful agent for Hyper-V plugin
Date Wed, 13 Mar 2013 00:08:50 GMT
Is this an accurate summary?
1. Design a REST-ful API that is functionally equivalent to the operations
provided in the agent-api package
2. Implement this in C# / .NET
3. Run one of these API servers on every hypervisor

+3 if my understanding is right.

If so, 
 - how would the vm orchestrator "find" the REST endpoint?
 - how would the vm orchestrator authenticate against the REST endpoint?
 - are there any cluster-level operations that would be implemented?

On 3/12/13 2:51 PM, "Donal Lafferty" <> wrote:

>I wanted to get some feedback on a shift to a remote agent for the next
>phase of Hyper-V development.
>Controlling Hyper-V directly from the management server makes image
>motion tricky.  A plugin could use WS-Management to remotely manage
>Windows subsystems such as Hyper-V; however, this does not provide an
>obvious means of downloading templates when they are stored in S3 or
>For Phase 2, I'd like to revise the Hyper-V plugin to use a native
>ServerResource with a RESTful API that is consumed by a generic
>The ServerComponents is 'generic', because it makes no assumptions beyond
>what is in the ServerResource's RESTful API.  Instead of using the
>message bus, the ServerComponent would convert existing Agent commands to
>GET and POST HTTP methods.  With the message bus gone, the remote agent
>no longer needs to be started using outside tools (e.g. KVM uses SSH).
>Ideally the generic ServerComponent would not have to be customised for
>the type of hypervisor it was talking to.
>The ServerResource is 'native', because it would run on the hypervisor
>and be implemented in a well-supported language.  By well-supported, I
>mean the remote agent would be implemented in a language designed to call
>the hypervisor's API library directly.  The Java agent used in Hyper-V
>Phase 1 needed scripts to call theHyper-V API, and these were launched in
>a separate process outside the JVM.  For Phase 2, using C# and the .NET
>framework would avoid spinning up this separate process.  Also, the
>ServerResource would have access to the Hypervisor's file system and
>attached devices, which provides more flexibility for downloading and
>writing a disk image to primary storage.  Therefore, the native
>ServerResource gets to exploit the hypervisor's development ecosystem
>Any comments on this approach, or the IP and technology limits that using
>C# / .NET implies would be most welcome.

View raw message