Frank, thanks for the architectural explanation. The Manager based approach looks more interesting in this case, as it's probably easier to deploy only the .Net assemblies + JSON APIs and writing a custom resource. I'm of course open to any idea at this stage. I'll start digging into the CS code today.
About the Agent based option: How do you handle the authentication between CS and the Agents on hypervisor hosts? Do you have a common authentication / identity framework? Alessandro On Apr 20, 2012, at 02:30 , Frank Zhang wrote: > > > There's a JSON-based protocol to pass commands between Management Server > > and host. > > >> That sounds great! Do you maybe have a link for some documentation and > >> samples? :) > CloudStack has two types of managing host. Agent based and > manager based. Agent based means installing an agent on host and management > server directly controls host through the agent. KVM and XenServer falls into > this category, as KVM agent is written by CloudStack developer while agent > of XenServer is provided by Xapi. The manager based approach applies to > VMWare, HyperV, OVM3 where CloudStack invokes API of SDK provided by > hypervisor vendor to communicate with *the manager*, for example, VCenter of > VMWare, the manager is on behalf of CloudStack to control the host. in our > code paths, these two approaches look like: > > 1. Agent Based: > CloudStack business logic -------à Resource -----(XMLRPC or something) > ---------à Agent on host > 2. Manager Based: > CloudStack business logic ------à Resource -----(API in SDK) ----------à > hypervisor manager provided by vendor ------à host > > To support a new type of hypervisor, the key is to implement > a *Resource* showed in above. The Resource is a command executor which > receives commands from CloudStack business logic(known as various managers, > like networkManager, StorageManager, UserVmManager … in our code) and > performs these commands to hypervisor by means of either XmlRpc or SDK API. > In GoF design patterns, the Resource is a proxy pattern that works as a > surrogate between CloudStack and hypervisors. > If you open one of hypervisor resources source file (for > example, VmwareResource.java, LibvirtComputingResource.java, > CitrixResourceBase.java), you will find all of them implement the same set of > commands that are exhibited by method: > public Answer executeRequest(Command cmd) > > take a look at that method and implement a similar resource like others, then > you add HyperV support into CloudStackJ > > > Thanks, > > Alessandro > > > On Apr 19, 2012, at 19:16 , Kevin Kluge wrote: > > > Yes, very interesting. Can you elaborate on the getThumbnail function. > One issue we have been thinking about with Hyper-V is how to do guest console > display (console proxy functionality, in CloudStack terms). Since only RDP > is available with Hyper-V, and CloudStack knows only VNC, we've been > expecting that RDP is needed in CloudStack to provide console view. > > Did you integrate with Hyper-V in Windows Server 2008 R2? Or something else? > > The CloudStack has existing code/framework to implement what we call a remote > agent (your scenario 3). Take a look at how KVM hosts are managed. > There's a JSON-based protocol to pass commands between Management Server and > host. > > -kevin > > > > -----Original Message----- > From: Rajesh Battala [mailto:[email protected]] > Sent: Thursday, April 19, 2012 8:59 AM > To: [email protected] > Subject: RE: Hyper-V Support > > Idea is great. > All these Hyper-V operations are implement to manage the Hyper-V box > directly using WMI calls right? > Or these operations are implemented via SCVMM? > > Thanks > Rajesh Battala > > > > > -----Original Message----- > From: Alessandro Pilotti [mailto:[email protected]] > Sent: Thursday, April 19, 2012 9:02 PM > To: [email protected] > Cc: [email protected] > Subject: Hyper-V Support > > Hi guys, > > I'm new to this list, so hi everybody :-) > > I'm interested in providing code for integrating Cloudstack with Hyper-V. We > developend an Hyper-V management framework that we use in our cloud > products that can be used (at least as as a starting point). > > I'm summing up at the bottom of this email what we already have in terms of > Hyper-V features handled by our framework (completed and tested). We > basically cover everything needed for CloudStack and more. :-) > > Beside that we also just released an open source Hyper-V backup library and > CLI tool: http://hypervbackup.codeplex.com/ So far it's the only open source > tool handling VSS backups of VMs on CSV storage :-) > > The assemblies are written in C# with .Net as the only dependency. > > I see 3 options to integrate our work with CloudStack: > > Write a Java adapter on top of the C# assembly (via JNI) Rewrite the C# code > in Java, considering the quirkness for accessing WMI from java (jWMI, etc) > Deploy the assembly on the Hyper-V hosts and add a RESTful layer on top to > be consumed by a Java adapter (locally or remotely). That would be the best > option in terms of performance and security (and the fastest to release :-) ). > > I prefer the third option, but I'm open to any idea! > Looking forward for your opinion! > > BTW We plan to setup a CloudStack Hyper-V service in our datacenter on top > of one of the clusters as soon as we have a working beta. > > > Thanks, > > Alessandro Pilotti > Cloudbase Solutions Srl > ------------------------------------------------------------ > IT Consultant & Technical Speaker > > MVP ASP.Net / IIS > MCSD, MCAD, MCSE, MCDBA, MCTS, MCT > RHCE - Red Hat Certified Engineer > ------------------------------------------------------------ > > > > VM > Create > Update > Delete > Add / update / remove any type of resource (ethernet emulated/synthetic > adapther, VHDs, ISO images etc) List Get summary Get thumbnail Get > integration tools status and KV data Get IP addresses Start Stop Pause Save > Shutdown Take snapshot List snapshots Revert to snapshot Remove > snapshots Export Import Network > > Create VirtualSwitch > Delete VirtualSwitch > List VirtualSwitches > Create VirtualSwitch port > remove VirtualSwitch port > Bind external ethernet port > Setup VirtualSwitch (connect to external ethernet port) Terdown switch > Create internal ethernet port Remove internal ethernet port Connect > VirtualSwitch port to VM or other ports Disconnect VirtualSwitch port > > Storage > > Create VHD (fixed, dynamic, differencing) Compact VHD Convert VHD type > Merge VHD with parent Validate VHD Mount / unmount VHD Reconnect > parent VHD Get VHD info Expand VHD Create Virtual Floppy Disk > > Utility > > Get async job info > Wait for async job info > Remote file system management > > Cluster > > Create VM resource > Remove VM resource > Live migrate VM > Create CSV > Move CSV > > Backup / Restore > > http://hypervbackup.codeplex.com/ > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2_______________________________________________ > cloudstack-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/cloudstack-devel
