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 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 directly. Any comments on this approach, or the IP and technology limits that using C# / .NET implies would be most welcome. DL
