incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donal Lafferty <>
Subject [DISCUSS] RESTful agent for Hyper-V plugin
Date Tue, 12 Mar 2013 21:51:32 GMT
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 Swift.

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 ServerComponent.

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

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 directly.

Any comments on this approach, or the IP and technology limits that using C# / .NET implies
would be most welcome.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message