incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohammad Nour El-Din <nour.moham...@gmail.com>
Subject Re: [cloudstack-devel] Hyper-V Support
Date Fri, 20 Apr 2012 00:09:23 GMT
On Fri, Apr 20, 2012 at 1:30 AM, Frank Zhang <Frank.Zhang@citrix.com> 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 CloudStack:)
>

Pretty cool, actually thats explained make me in favor for both options 2
&3 for deployment scenarios:

1- (Option 2 assumed) In that scenario implementing the Resource in the
manager pattern way, which is better I believe performance wise if HyperV
is locally on the same machine
2- (Option 3 assumed) In that scenario implementing the Resource in the
Agent pattern way, which is in the case when you wanna handle a remote
HyperV

It is like Local and Remotes EJB idea which you can choose between them
according to which installation/deployment you have and hence have the best
performance easily tweaked


>
>
> 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:rajesh.battala@citrix.com]<mailto:[mailto:
> rajesh.battala@citrix.com]>
> Sent: Thursday, April 19, 2012 8:59 AM
> To: cloudstack-dev@incubator.apache.org<mailto:
> cloudstack-dev@incubator.apache.org>
> 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:ap@pilotti.it]<mailto:[mailto:
> ap@pilotti.it]>
> Sent: Thursday, April 19, 2012 9:02 PM
> To: cloudstack-dev@incubator.apache.org<mailto:
> cloudstack-dev@incubator.apache.org>
> Cc: cloudstack-devel@lists.sourceforge.net<mailto:
> cloudstack-devel@lists.sourceforge.net>
> 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<http://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/
>
>
>


-- 
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

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