RE: [cloudstack-devel] Hyper-V Support

[Frank Zhang <Fr...@citrix.com>]

> 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:)


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<ma...@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<ma...@incubator.apache.org>
Cc: cloudstack-devel@lists.sourceforge.net<ma...@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/

RE: [cloudstack-devel] Hyper-V Support

[Kelven Yang <ke...@citrix.com>]

Alessandro,

Your points make a lot of sense, orchestrating with yet another external management server like SCVMM and vCenter is a lot complex than orchestrating host directly.

With agent mode (orchestrating host directly), the next question you might want to answer is to how to deploy and automatically upgrade agent to hyper-V hosts, majority of CloudStack management server deployments are running on non-Microsoft systems. We use SSH based approach to deploy KVM agent and XS plugin, not sure if there is any WMI based java implementation available to help finish the job to remotely push agent software from management server to Hyper-V host, this can greatly improve the user experience. 

If not so, it may be worth to develop a WMI/PowerShell broker service to help orchestrate Hyper-V host natively in WMI or Powershell from CloudStack.

Although it is still a valid option to just follow existing CloudStack java agent approach, let the java agent take CloudStack management server JSON commands which in turn to call native WMI/PowerShell on Hyper-V host, I'm wondering that if you already have a PowerShell/WMI repo of hyper-V orchestrating building blocks, a PowerShell/WMI broker in this situation might be a better option. With this option, you may launch a agent-proxy inside CloudStack management server, and remotely run native PowerShell natively via the broker service (similar to remote SSH).

Kelven


-----Original Message-----
From: Alessandro Pilotti [mailto:ap@pilotti.it] 
Sent: Saturday, April 21, 2012 11:05 AM
To: cloudstack-dev@incubator.apache.org
Cc: cloudstack-devel@lists.sourceforge.net
Subject: Re: [cloudstack-devel] Hyper-V Support

Hi,

we also thought about SCVMM integration vs direct management of the hosts when we started developing our management solution.

We decided against it in our scenario for the following reasons:
SCVMM does not provide significant features that the hosts cannot provide directly
SCVMM is definitily not a free product
SCVMM introduces additional architectural requirements and complexities
SCVMM overlaps with CS in a lot of areas
The only reason where it might be useful to provide integration with SCVMM is for customers that want to run CS on top of an existing SCVMM infrastructure.
This means that we'd also like to provide adapters for this scenario at a later stage, which is not a problem as SCVMM provides a rich PowerSell set of APIs that we can wrap.  

Your architectural parallel between SCVMM and vSphere is correct, with the difference that the fault tolerant features (e.g Live Migration) are handled by the operating system itself, not by SCVMM (we already support them in our framework). In VMWare case, those features (vMotion etc) are handled by vSphere not by ESX/ESXi. 

Let me know what do you guys think about it!


Alessandro Pilotti
MVP ASP.Net / IIS



On Apr 21, 2012, at 05:52 , Kevin Kluge wrote:

> Alessandro, one other question -- can you explain the rationale for managing Hyper-V directly, as opposed to going through SCVMM?  CloudStack's VMware integration goes through vCenter.  We chose that model since we heard from users that VMware administrators liked using vCenter as a management point.  Also, there are some features that are implemented by vCenter that a direct-host management integration could not provide without re-implementing similar functionality itself.  I had assumed that a Hyper V integration would have similar issues , suggesting management via SCVMM would be advantageous, but I am relatively less familiar with Hyper-V technology and administrator preferences.   Thoughts?   Are there any features that we "lose" by going direct to host versus through SCVMM?
> 
> -kevin

Re: [cloudstack-devel] Hyper-V Support

[Alessandro Pilotti <ap...@pilotti.it>]

Hi,

we also thought about SCVMM integration vs direct management of the hosts when we started developing our management solution.

We decided against it in our scenario for the following reasons:
SCVMM does not provide significant features that the hosts cannot provide directly
SCVMM is definitily not a free product
SCVMM introduces additional architectural requirements and complexities
SCVMM overlaps with CS in a lot of areas
The only reason where it might be useful to provide integration with SCVMM is for customers that want to run CS on top of an existing SCVMM infrastructure.
This means that we'd also like to provide adapters for this scenario at a later stage, which is not a problem as SCVMM provides a rich PowerSell set of APIs that we can wrap.  

Your architectural parallel between SCVMM and vSphere is correct, with the difference that the fault tolerant features (e.g Live Migration) are handled by the operating system itself, not by SCVMM (we already support them in our framework). In VMWare case, those features (vMotion etc) are handled by vSphere not by ESX/ESXi. 

Let me know what do you guys think about it!


Alessandro Pilotti
MVP ASP.Net / IIS



On Apr 21, 2012, at 05:52 , Kevin Kluge wrote:

> Alessandro, one other question -- can you explain the rationale for managing Hyper-V directly, as opposed to going through SCVMM?  CloudStack's VMware integration goes through vCenter.  We chose that model since we heard from users that VMware administrators liked using vCenter as a management point.  Also, there are some features that are implemented by vCenter that a direct-host management integration could not provide without re-implementing similar functionality itself.  I had assumed that a Hyper V integration would have similar issues , suggesting management via SCVMM would be advantageous, but I am relatively less familiar with Hyper-V technology and administrator preferences.   Thoughts?   Are there any features that we "lose" by going direct to host versus through SCVMM?
> 
> -kevin

RE: [cloudstack-devel] Hyper-V Support

[Kevin Kluge <Ke...@citrix.com>]

Alessandro, one other question -- can you explain the rationale for managing Hyper-V directly, as opposed to going through SCVMM?  CloudStack's VMware integration goes through vCenter.  We chose that model since we heard from users that VMware administrators liked using vCenter as a management point.  Also, there are some features that are implemented by vCenter that a direct-host management integration could not provide without re-implementing similar functionality itself.  I had assumed that a Hyper V integration would have similar issues , suggesting management via SCVMM would be advantageous, but I am relatively less familiar with Hyper-V technology and administrator preferences.   Thoughts?   Are there any features that we "lose" by going direct to host versus through SCVMM?

-kevin

Re: [cloudstack-devel] Hyper-V Support

[Mohammad Nour El-Din <no...@gmail.com>]

Hi

On Fri, Apr 20, 2012 at 2:24 AM, Frank Zhang <Fr...@citrix.com> wrote:

>
> 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
>
Does HyperV provide direct access to its agent ?
>

That also would be a good idea, but honestly IDK, I am looking in HyperV
now, I worked more with VirtualBox, but if not as suggested by Alessandro
to be wrapped with a remoting layer


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



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

RE: [cloudstack-devel] Hyper-V Support

[Frank Zhang <Fr...@citrix.com>]

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
Does HyperV provide direct access to its agent ?

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

Re: [cloudstack-devel] Hyper-V Support

[Mohammad Nour El-Din <no...@gmail.com>]

On Fri, Apr 20, 2012 at 1:30 AM, Frank Zhang <Fr...@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

Re: [cloudstack-devel] Hyper-V Support

[David Nalley <da...@gnsa.us>]

On Fri, Jun 1, 2012 at 7:23 AM, Alessandro Pilotti <ap...@pilotti.it> wrote:
> Hi guys,
>
> we are moving forward pretty fast in the development of support for Hyper-V, we'll be able to share the first bits hopefully very soon. :-)

Alessandro,

This is great to hear, I was actually planning on pinging you next
week to see how things were proceeding. I am thrilled to hear that you
are making rapid progress - any of the bits you have already in a
place that's public?

--David

RE: [cloudstack-devel] Hyper-V Support

[Nitin Mehta <Ni...@citrix.com>]

Hi Alessandro,
SSVM needs to have agent running which connects to MS on port 8250 (it is a remote agent). The responsibility of this agent is to take commands from MS and take some action.
One example of this is - MS instructing the SSVM to download a template on secondary storage and the agent doing to real work of downloading it.

You can just simulate an agent which can understand these commands to get going (Look at NfsSecondaryStorageResource.java for all the commands SSVM agent understands)

Thanks,
-Nitin

-----Original Message-----
From: Alessandro Pilotti [mailto:ap@pilotti.it]
Sent: Friday, June 01, 2012 6:16 PM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: Re: [cloudstack-devel] Hyper-V Support

Hi Rajesh,

here's the error. It happens when we try to add a template. We need to find a way to replace this with a dummy implementation.

[java] WARN  [storage.download.DownloadMonitorImpl] (http-8080-5:) There is no secondary storage VM for secondary storage host nfs://10.73.76.36/export/secondary

The fake secondary storage VM exists and is shown as in "Running" state in the admin panel.


Thanks!

Alessandro




On Jun 1, 2012, at 15:06 , Rajesh Battala wrote:

> Can you please send the error in detail and log which can help us to find what is the error.
>
> Thanks
> Rajesh Battala
>
>> -----Original Message-----
>> From: Alessandro Pilotti [mailto:ap@pilotti.it]
>> Sent: Friday, June 01, 2012 4:53 PM
>> To: cloudstack-dev@incubator.apache.org
>> Cc: Development discussions for CloudStack
>> Subject: Re: [cloudstack-devel] Hyper-V Support
>>
>> Hi guys,
>>
>> we are moving forward pretty fast in the development of support for
>> Hyper- V, we'll be able to share the first bits hopefully very soon.
>> :-)
>>
>> In the meantime we have a small problem to solve with the secondary
>> storage: in our test environment, we created a dummy Hyper-V
>> resource, but we have troubles in deploying dummy instances as
>> CloudStack cannot see and initialize a secondary storage.
>>
>> Do you have any suggestion on how to get around that?
>>
>>
>> Thanks!
>>
>> Alessandro Pilotti
>> Cloudbase Solutions Srl
>> ------------------------------------------------------------
>> IT Consultant & Technical Speaker
>>
>> MVP ASP.Net / IIS
>> Windows Azure Insider
>> Microsoft Certified Professional & Trainer MCSD, MCAD, MCSE, MCDBA,
>> MCTS, MCT RHCE - Red Hat Certified Engineer
>> ------------------------------------------------------------
>>
>>
>>
>>
>> On Apr 22, 2012, at 03:54 , Kelven Yang wrote:
>>
>>>>> 1) I'm looking at the commands in com.cloud.agent.api. Is there
>>>>> some
>> documentation?
>>> Unfortunately, we haven't put a detail document on this. Vmware or
>> XenServer resource is a good place to look at
>>>
>>>>> 2) Commands are synchronous or asynchronous? In case how do you
>> handle running jobs?
>>>
>>> There is a design principal that command executors are dumb
>>> executors,
>> the command flow business logic should be implemented in
>> corresponding managers running inside management server, therefore a
>> resource implementation will be easily hosted either locally within
>> the management server or remotely at agent side.
>>>
>>> Command is usually executed synchronously(we actually provides
>> mechanism to execute command asynchronously), managers can schedule
>> asynchronous jobs.
>>>
>>>>> 3) Configuration: how do I tell CS that a new HyperVisor Resource
>>>>> type
>> exists? (both cases: Manager based / Agent based)
>>> To add a new hypervisor, there are a number of things you need to do
>> together,
>>>     1) Hypervisor.java, add a new type into the enum
>>>     2) Config.java, add the new type to HypervisorList so that UI may
>>> be
>> aware of
>>>     3) Add the resource discover class, refer to
>>> XcpServerDiscover.java,
>> KvmServerDiscover.java, etc
>>>     4) Add the resource class(for managed resource), refer to
>> VmwareResource.java/CitrixResourceBase.java, etc.
>>>     5) Populate guest OS types and system template data for the
>> hypervisor to database, refer to create-schema.sql and template.sql
>>>     6) Prepare the default system template for the hypervisor
>>>
>>>>> 4) Storage:
>>> This is the part that needs a lot of discussions.
>>> We are talking about secondary storage. Usually only hypervisor host
>>> and
>> storage system VM need to access to it, VMware does one special step
>> that management server needs to access to it to bootstrap system VMs.
>> So to support hybrid deployment option, we would require secondary
>> storage to be accessible from all of them, giving the fact that
>> Xen/KVM/VMware only supports NFS shares, it would be better to make
>> secondary storage dual faces for Hyper-V, in this way, the same
>> secondary storage will be able to serve XenServer/VMware/KVM/Hyper-V within the same zone.
>>>
>>> We do have a Hyper-V prototype in current CloudStack code base, you
>>> may
>> also want to check it out before you start.
>>>
>>> Kelven
>>>
>>>
>>> -----Original Message-----
>>> From: Alessandro Pilotti [mailto:ap@pilotti.it]
>>> Sent: Saturday, April 21, 2012 1:35 PM
>>> To: cloudstack-dev@incubator.apache.org
>>> Cc: Development discussions for CloudStack
>>> Subject: Re: [cloudstack-devel] Hyper-V Support
>>>
>>> I started looking into the code for VMWare and KVM resources in
>>> order to
>> develop the Hyper-V Resource, the proxy based architecture is clear.
>>>
>>>
>>> I have some basic questions to start with :-)
>>>
>>> 1) I'm looking at the commands in com.cloud.agent.api. Is there some
>> documentation? To start coding the HyperV adapter, is there a list of
>> mandatory and optional commands? I'm "reverse engineering" their
>> semantyc looking at the VMWare resources, but it's not so trivial :)
>>>
>>> 2) Commands are synchronous or asynchronous? In case how do you
>> handle running jobs?
>>>
>>> 3) Configuration: how do I tell CS that a new HyperVisor Resource
>>> type
>> exists? (both cases: Manager based / Agent based)
>>>
>>> 4) Storage: the free Hyper-V server does not contain an NFS client.
>>> There
>> are of course open source NFS clients (Cygwin, etc) that can be
>> installed, but supporting SMB might be easier. What do you think
>> about adding support for SMB shares in CS?
>>>
>>>
>>>
>>> Thanks!
>>>
>>> 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:rajesh.battala@citrix.com]
>>>> Sent: Thursday, April 19, 2012 8:59 AM
>>>> To: 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]
>>>> Sent: Thursday, April 19, 2012 9:02 PM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Cc: 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 / 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
>>>> cloudstack-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/cloudstack-devel
>>>
>

RE: [cloudstack-devel] Hyper-V Support

[Edison Su <Ed...@citrix.com>]

> -----Original Message-----
> From: Alessandro Pilotti [mailto:ap@pilotti.it]
> Sent: Tuesday, August 07, 2012 3:06 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [cloudstack-devel] Hyper-V Support
> 
> Hi guys,
> 
> we have some trouble with NFS to access the secondary storage as we are
> targetting Hyper-V server which, unlike Windows Server, doesn't have a
> native NFS client.
> 
> How hard do you guys think it would be to add CIFS as an alternative to
> NFS in CloudStack?

Need to do the following:
1. Add a secondary CIFS resource, like NfsSecondaryStorageResource, which will be running inside SSVM. The main responsibility for this resource is to download templates from public network into CIFS storage. CifsSecondaryStorageResource is already in the code, but not sure what's status of it. 
2. Add the CIFS code in your hyperv-v resource, for commands like, PrimaryStorageDownloadCommand(which will download template from CIFS storage)
3. Add CIFS support in AddSecondaryStorageCmd(the code is in discoverHostsFull in ResourceManagerImpl)

> 
> 
> Thanks!
> 
> Alessandro Pilotti
> Cloudbase Solutions Srl
> -------------------------------------
> MVP ASP.Net / IIS
> Windows Azure Insider
> Red Hat Certified Engineer
> -------------------------------------
> 
> 
> 
> 
> On Jul 5, 2012, at 18:19 , David Nalley <da...@gnsa.us> wrote:
> 
> > Hi Alessandro:
> >
> > I just wanted to check and see how things were going and what kind of
> > progress you were making. Is there anything we can help you with?
> >
> > --David

Re: [cloudstack-devel] Hyper-V Support

[David Nalley <da...@gnsa.us>]

On Tue, Aug 7, 2012 at 6:05 AM, Alessandro Pilotti <ap...@pilotti.it> wrote:
> Hi guys,
>
> we have some trouble with NFS to access the secondary storage as we are targetting Hyper-V server which, unlike Windows Server, doesn't have a native NFS client.
>
> How hard do you guys think it would be to add CIFS as an alternative to NFS in CloudStack?
>
>
> Thanks!
>

Alessandro -

Is there a place where we can see what you have thus far (github
perhaps?), perhaps others could help as well.

--David

Re: [cloudstack-devel] Hyper-V Support

[Murali Reddy <Mu...@citrix.com>]

On 07/08/12 3:35 PM, "Alessandro Pilotti" <ap...@pilotti.it> wrote:

>Hi guys,
>
>we have some trouble with NFS to access the secondary storage as we are
>targetting Hyper-V server which, unlike Windows Server, doesn't have a
>native NFS client.
>
>How hard do you guys think it would be to add CIFS as an alternative to
>NFS in CloudStack?

Its not that hard to support CIFS as secondary storage with limitations.
Just the way there is no native support for Hyper-V/Windows server to use
NFS shared storage, I doubt if there is support for CIFS across the
hypervisors (Xen, vSphere, Kvm, Ovm) that CloudStack supports today. So
multi-hypervisor CloudStack deployment with CIFS as only secondary storage
does not work. If we impose, in order to use CIFS as secondary storage a
zone should only have Hyper-v hypervisors in the deployment then this may
not be issue. Alternatively in multi-hypervisor deployment one could add
both NFS and CIFS secondary storage, and tweak CloudStack
planner/allocators so that a VM created from template on CIFS storage is
launched only on Hyper-V hosts.

Please note that SSVM (secondary storage VM) also works with NFS secondary
storages only. In order to make SSVM handle CIFS, you can introduce a new
SecondaryStorageResource implementation for CIFS and change the way share
is mounted in SSVM. Most of the helper scripts and implemented
functionality on NfsSecondaryStorageResource should work.

>
>Thanks!
>
>Alessandro Pilotti
>Cloudbase Solutions Srl
>-------------------------------------
>MVP ASP.Net / IIS
>Windows Azure Insider
>Red Hat Certified Engineer
>-------------------------------------
>
>
>
>
>On Jul 5, 2012, at 18:19 , David Nalley <da...@gnsa.us> wrote:
>
>> Hi Alessandro:
>> 
>> I just wanted to check and see how things were going and what kind of
>> progress you were making. Is there anything we can help you with?
>> 
>> --David
>
>

Re: [cloudstack-devel] Hyper-V Support

[Alessandro Pilotti <ap...@pilotti.it>]

Hi guys,

we have some trouble with NFS to access the secondary storage as we are targetting Hyper-V server which, unlike Windows Server, doesn't have a native NFS client.

How hard do you guys think it would be to add CIFS as an alternative to NFS in CloudStack?


Thanks!

Alessandro Pilotti
Cloudbase Solutions Srl
-------------------------------------
MVP ASP.Net / IIS
Windows Azure Insider
Red Hat Certified Engineer 
-------------------------------------




On Jul 5, 2012, at 18:19 , David Nalley <da...@gnsa.us> wrote:

> Hi Alessandro:
> 
> I just wanted to check and see how things were going and what kind of
> progress you were making. Is there anything we can help you with?
> 
> --David

Re: [cloudstack-devel] Hyper-V Support

[David Nalley <da...@gnsa.us>]

Hi Alessandro:

I just wanted to check and see how things were going and what kind of
progress you were making. Is there anything we can help you with?

--David

Re: [cloudstack-devel] Hyper-V Support

[Alessandro Pilotti <ap...@pilotti.it>]

Hi Rajesh,

here's the error. It happens when we try to add a template. We need to find a way to replace this with a dummy implementation. 

[java] WARN  [storage.download.DownloadMonitorImpl] (http-8080-5:) There is no secondary storage VM for secondary storage host nfs://10.73.76.36/export/secondary

The fake secondary storage VM exists and is shown as in "Running" state in the admin panel. 


Thanks!

Alessandro




On Jun 1, 2012, at 15:06 , Rajesh Battala wrote:

> Can you please send the error in detail and log which can help us to find what is the error. 
> 
> Thanks
> Rajesh Battala
> 
>> -----Original Message-----
>> From: Alessandro Pilotti [mailto:ap@pilotti.it]
>> Sent: Friday, June 01, 2012 4:53 PM
>> To: cloudstack-dev@incubator.apache.org
>> Cc: Development discussions for CloudStack
>> Subject: Re: [cloudstack-devel] Hyper-V Support
>> 
>> Hi guys,
>> 
>> we are moving forward pretty fast in the development of support for Hyper-
>> V, we'll be able to share the first bits hopefully very soon. :-)
>> 
>> In the meantime we have a small problem to solve with the secondary
>> storage: in our test environment, we created a dummy Hyper-V resource,
>> but we have troubles in deploying dummy instances as CloudStack cannot
>> see and initialize a secondary storage.
>> 
>> Do you have any suggestion on how to get around that?
>> 
>> 
>> Thanks!
>> 
>> Alessandro Pilotti
>> Cloudbase Solutions Srl
>> ------------------------------------------------------------
>> IT Consultant & Technical Speaker
>> 
>> MVP ASP.Net / IIS
>> Windows Azure Insider
>> Microsoft Certified Professional & Trainer MCSD, MCAD, MCSE, MCDBA,
>> MCTS, MCT RHCE - Red Hat Certified Engineer
>> ------------------------------------------------------------
>> 
>> 
>> 
>> 
>> On Apr 22, 2012, at 03:54 , Kelven Yang wrote:
>> 
>>>>> 1) I'm looking at the commands in com.cloud.agent.api. Is there some
>> documentation?
>>> Unfortunately, we haven't put a detail document on this. Vmware or
>> XenServer resource is a good place to look at
>>> 
>>>>> 2) Commands are synchronous or asynchronous? In case how do you
>> handle running jobs?
>>> 
>>> There is a design principal that command executors are dumb executors,
>> the command flow business logic should be implemented in corresponding
>> managers running inside management server, therefore a resource
>> implementation will be easily hosted either locally within the management
>> server or remotely at agent side.
>>> 
>>> Command is usually executed synchronously(we actually provides
>> mechanism to execute command asynchronously), managers can schedule
>> asynchronous jobs.
>>> 
>>>>> 3) Configuration: how do I tell CS that a new HyperVisor Resource type
>> exists? (both cases: Manager based / Agent based)
>>> To add a new hypervisor, there are a number of things you need to do
>> together,
>>> 	1) Hypervisor.java, add a new type into the enum
>>> 	2) Config.java, add the new type to HypervisorList so that UI may be
>> aware of
>>> 	3) Add the resource discover class, refer to XcpServerDiscover.java,
>> KvmServerDiscover.java, etc
>>> 	4) Add the resource class(for managed resource), refer to
>> VmwareResource.java/CitrixResourceBase.java, etc.
>>> 	5) Populate guest OS types and system template data for the
>> hypervisor to database, refer to create-schema.sql and template.sql
>>> 	6) Prepare the default system template for the hypervisor
>>> 
>>>>> 4) Storage:
>>> This is the part that needs a lot of discussions.
>>> We are talking about secondary storage. Usually only hypervisor host and
>> storage system VM need to access to it, VMware does one special step that
>> management server needs to access to it to bootstrap system VMs. So to
>> support hybrid deployment option, we would require secondary storage to
>> be accessible from all of them, giving the fact that Xen/KVM/VMware only
>> supports NFS shares, it would be better to make secondary storage dual
>> faces for Hyper-V, in this way, the same secondary storage will be able to
>> serve XenServer/VMware/KVM/Hyper-V within the same zone.
>>> 
>>> We do have a Hyper-V prototype in current CloudStack code base, you may
>> also want to check it out before you start.
>>> 
>>> Kelven
>>> 
>>> 
>>> -----Original Message-----
>>> From: Alessandro Pilotti [mailto:ap@pilotti.it]
>>> Sent: Saturday, April 21, 2012 1:35 PM
>>> To: cloudstack-dev@incubator.apache.org
>>> Cc: Development discussions for CloudStack
>>> Subject: Re: [cloudstack-devel] Hyper-V Support
>>> 
>>> I started looking into the code for VMWare and KVM resources in order to
>> develop the Hyper-V Resource, the proxy based architecture is clear.
>>> 
>>> 
>>> I have some basic questions to start with :-)
>>> 
>>> 1) I'm looking at the commands in com.cloud.agent.api. Is there some
>> documentation? To start coding the HyperV adapter, is there a list of
>> mandatory and optional commands? I'm "reverse engineering" their
>> semantyc looking at the VMWare resources, but it's not so trivial :)
>>> 
>>> 2) Commands are synchronous or asynchronous? In case how do you
>> handle running jobs?
>>> 
>>> 3) Configuration: how do I tell CS that a new HyperVisor Resource type
>> exists? (both cases: Manager based / Agent based)
>>> 
>>> 4) Storage: the free Hyper-V server does not contain an NFS client. There
>> are of course open source NFS clients (Cygwin, etc) that can be installed, but
>> supporting SMB might be easier. What do you think about adding support for
>> SMB shares in CS?
>>> 
>>> 
>>> 
>>> Thanks!
>>> 
>>> 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:rajesh.battala@citrix.com]
>>>> Sent: Thursday, April 19, 2012 8:59 AM
>>>> To: 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]
>>>> Sent: Thursday, April 19, 2012 9:02 PM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Cc: 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 / 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
>>>> cloudstack-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/cloudstack-devel
>>> 
> 

RE: [cloudstack-devel] Hyper-V Support

[Rajesh Battala <ra...@citrix.com>]

Can you please send the error in detail and log which can help us to find what is the error. 

Thanks
Rajesh Battala

> -----Original Message-----
> From: Alessandro Pilotti [mailto:ap@pilotti.it]
> Sent: Friday, June 01, 2012 4:53 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Development discussions for CloudStack
> Subject: Re: [cloudstack-devel] Hyper-V Support
> 
> Hi guys,
> 
> we are moving forward pretty fast in the development of support for Hyper-
> V, we'll be able to share the first bits hopefully very soon. :-)
> 
> In the meantime we have a small problem to solve with the secondary
> storage: in our test environment, we created a dummy Hyper-V resource,
> but we have troubles in deploying dummy instances as CloudStack cannot
> see and initialize a secondary storage.
> 
> Do you have any suggestion on how to get around that?
> 
> 
> Thanks!
> 
> Alessandro Pilotti
> Cloudbase Solutions Srl
> ------------------------------------------------------------
> IT Consultant & Technical Speaker
> 
> MVP ASP.Net / IIS
> Windows Azure Insider
> Microsoft Certified Professional & Trainer MCSD, MCAD, MCSE, MCDBA,
> MCTS, MCT RHCE - Red Hat Certified Engineer
> ------------------------------------------------------------
> 
> 
> 
> 
> On Apr 22, 2012, at 03:54 , Kelven Yang wrote:
> 
> >>> 1) I'm looking at the commands in com.cloud.agent.api. Is there some
> documentation?
> > Unfortunately, we haven't put a detail document on this. Vmware or
> XenServer resource is a good place to look at
> >
> >>> 2) Commands are synchronous or asynchronous? In case how do you
> handle running jobs?
> >
> > There is a design principal that command executors are dumb executors,
> the command flow business logic should be implemented in corresponding
> managers running inside management server, therefore a resource
> implementation will be easily hosted either locally within the management
> server or remotely at agent side.
> >
> > Command is usually executed synchronously(we actually provides
> mechanism to execute command asynchronously), managers can schedule
> asynchronous jobs.
> >
> >>> 3) Configuration: how do I tell CS that a new HyperVisor Resource type
> exists? (both cases: Manager based / Agent based)
> > To add a new hypervisor, there are a number of things you need to do
> together,
> > 	1) Hypervisor.java, add a new type into the enum
> > 	2) Config.java, add the new type to HypervisorList so that UI may be
> aware of
> > 	3) Add the resource discover class, refer to XcpServerDiscover.java,
> KvmServerDiscover.java, etc
> > 	4) Add the resource class(for managed resource), refer to
> VmwareResource.java/CitrixResourceBase.java, etc.
> > 	5) Populate guest OS types and system template data for the
> hypervisor to database, refer to create-schema.sql and template.sql
> > 	6) Prepare the default system template for the hypervisor
> >
> >>> 4) Storage:
> > This is the part that needs a lot of discussions.
> > We are talking about secondary storage. Usually only hypervisor host and
> storage system VM need to access to it, VMware does one special step that
> management server needs to access to it to bootstrap system VMs. So to
> support hybrid deployment option, we would require secondary storage to
> be accessible from all of them, giving the fact that Xen/KVM/VMware only
> supports NFS shares, it would be better to make secondary storage dual
> faces for Hyper-V, in this way, the same secondary storage will be able to
> serve XenServer/VMware/KVM/Hyper-V within the same zone.
> >
> > We do have a Hyper-V prototype in current CloudStack code base, you may
> also want to check it out before you start.
> >
> > Kelven
> >
> >
> > -----Original Message-----
> > From: Alessandro Pilotti [mailto:ap@pilotti.it]
> > Sent: Saturday, April 21, 2012 1:35 PM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: Development discussions for CloudStack
> > Subject: Re: [cloudstack-devel] Hyper-V Support
> >
> > I started looking into the code for VMWare and KVM resources in order to
> develop the Hyper-V Resource, the proxy based architecture is clear.
> >
> >
> > I have some basic questions to start with :-)
> >
> > 1) I'm looking at the commands in com.cloud.agent.api. Is there some
> documentation? To start coding the HyperV adapter, is there a list of
> mandatory and optional commands? I'm "reverse engineering" their
> semantyc looking at the VMWare resources, but it's not so trivial :)
> >
> > 2) Commands are synchronous or asynchronous? In case how do you
> handle running jobs?
> >
> > 3) Configuration: how do I tell CS that a new HyperVisor Resource type
> exists? (both cases: Manager based / Agent based)
> >
> > 4) Storage: the free Hyper-V server does not contain an NFS client. There
> are of course open source NFS clients (Cygwin, etc) that can be installed, but
> supporting SMB might be easier. What do you think about adding support for
> SMB shares in CS?
> >
> >
> >
> > Thanks!
> >
> > 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:rajesh.battala@citrix.com]
> >> Sent: Thursday, April 19, 2012 8:59 AM
> >> To: 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]
> >> Sent: Thursday, April 19, 2012 9:02 PM
> >> To: cloudstack-dev@incubator.apache.org
> >> Cc: 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 / 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
> >> cloudstack-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/cloudstack-devel
> >

Re: [cloudstack-devel] Hyper-V Support

[Alessandro Pilotti <ap...@pilotti.it>]

Hi guys,

we are moving forward pretty fast in the development of support for Hyper-V, we'll be able to share the first bits hopefully very soon. :-)

In the meantime we have a small problem to solve with the secondary storage: in our test environment, we created a dummy Hyper-V resource, but we have troubles in deploying dummy instances as CloudStack cannot see and initialize a secondary storage.

Do you have any suggestion on how to get around that?


Thanks!

Alessandro Pilotti
Cloudbase Solutions Srl
------------------------------------------------------------
IT Consultant & Technical Speaker
 
MVP ASP.Net / IIS
Windows Azure Insider
Microsoft Certified Professional & Trainer
MCSD, MCAD, MCSE, MCDBA, MCTS, MCT
RHCE - Red Hat Certified Engineer 
------------------------------------------------------------




On Apr 22, 2012, at 03:54 , Kelven Yang wrote:

>>> 1) I'm looking at the commands in com.cloud.agent.api. Is there some documentation?
> Unfortunately, we haven't put a detail document on this. Vmware or XenServer resource is a good place to look at
> 
>>> 2) Commands are synchronous or asynchronous? In case how do you handle running jobs?
> 
> There is a design principal that command executors are dumb executors, the command flow business logic should be implemented in corresponding managers running inside management server, therefore a resource implementation will be easily hosted either locally within the management server or remotely at agent side. 
> 
> Command is usually executed synchronously(we actually provides mechanism to execute command asynchronously), managers can schedule asynchronous jobs. 
> 
>>> 3) Configuration: how do I tell CS that a new HyperVisor Resource type exists? (both cases: Manager based / Agent based)
> To add a new hypervisor, there are a number of things you need to do together,
> 	1) Hypervisor.java, add a new type into the enum
> 	2) Config.java, add the new type to HypervisorList so that UI may be aware of
> 	3) Add the resource discover class, refer to XcpServerDiscover.java, KvmServerDiscover.java, etc
> 	4) Add the resource class(for managed resource), refer to VmwareResource.java/CitrixResourceBase.java, etc.
> 	5) Populate guest OS types and system template data for the hypervisor to database, refer to create-schema.sql and template.sql 
> 	6) Prepare the default system template for the hypervisor
> 	
>>> 4) Storage:
> This is the part that needs a lot of discussions.
> We are talking about secondary storage. Usually only hypervisor host and storage system VM need to access to it, VMware does one special step that management server needs to access to it to bootstrap system VMs. So to support hybrid deployment option, we would require secondary storage to be accessible from all of them, giving the fact that Xen/KVM/VMware only supports NFS shares, it would be better to make secondary storage dual faces for Hyper-V, in this way, the same secondary storage will be able to serve XenServer/VMware/KVM/Hyper-V within the same zone.
> 
> We do have a Hyper-V prototype in current CloudStack code base, you may also want to check it out before you start.
> 
> Kelven
> 
> 
> -----Original Message-----
> From: Alessandro Pilotti [mailto:ap@pilotti.it] 
> Sent: Saturday, April 21, 2012 1:35 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Development discussions for CloudStack
> Subject: Re: [cloudstack-devel] Hyper-V Support
> 
> I started looking into the code for VMWare and KVM resources in order to develop the Hyper-V Resource, the proxy based architecture is clear.
> 
> 
> I have some basic questions to start with :-)
> 
> 1) I'm looking at the commands in com.cloud.agent.api. Is there some documentation? To start coding the HyperV adapter, is there a list of mandatory and optional commands? I'm "reverse engineering" their semantyc looking at the VMWare resources, but it's not so trivial :)
> 
> 2) Commands are synchronous or asynchronous? In case how do you handle running jobs?
> 
> 3) Configuration: how do I tell CS that a new HyperVisor Resource type exists? (both cases: Manager based / Agent based)
> 
> 4) Storage: the free Hyper-V server does not contain an NFS client. There are of course open source NFS clients (Cygwin, etc) that can be installed, but supporting SMB might be easier. What do you think about adding support for SMB shares in CS?  
> 
> 
> 
> Thanks!
> 
> 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:rajesh.battala@citrix.com]
>> Sent: Thursday, April 19, 2012 8:59 AM
>> To: 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]
>> Sent: Thursday, April 19, 2012 9:02 PM
>> To: cloudstack-dev@incubator.apache.org
>> Cc: 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 / 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
>> cloudstack-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/cloudstack-devel
> 

RE: [cloudstack-devel] Hyper-V Support

[Kelven Yang <ke...@citrix.com>]

>> 1) I'm looking at the commands in com.cloud.agent.api. Is there some documentation?
Unfortunately, we haven't put a detail document on this. Vmware or XenServer resource is a good place to look at

>> 2) Commands are synchronous or asynchronous? In case how do you handle running jobs?

There is a design principal that command executors are dumb executors, the command flow business logic should be implemented in corresponding managers running inside management server, therefore a resource implementation will be easily hosted either locally within the management server or remotely at agent side. 

Command is usually executed synchronously(we actually provides mechanism to execute command asynchronously), managers can schedule asynchronous jobs. 

>> 3) Configuration: how do I tell CS that a new HyperVisor Resource type exists? (both cases: Manager based / Agent based)
To add a new hypervisor, there are a number of things you need to do together,
	1) Hypervisor.java, add a new type into the enum
	2) Config.java, add the new type to HypervisorList so that UI may be aware of
	3) Add the resource discover class, refer to XcpServerDiscover.java, KvmServerDiscover.java, etc
	4) Add the resource class(for managed resource), refer to VmwareResource.java/CitrixResourceBase.java, etc.
	5) Populate guest OS types and system template data for the hypervisor to database, refer to create-schema.sql and template.sql 
	6) Prepare the default system template for the hypervisor
	
>> 4) Storage:
This is the part that needs a lot of discussions.
We are talking about secondary storage. Usually only hypervisor host and storage system VM need to access to it, VMware does one special step that management server needs to access to it to bootstrap system VMs. So to support hybrid deployment option, we would require secondary storage to be accessible from all of them, giving the fact that Xen/KVM/VMware only supports NFS shares, it would be better to make secondary storage dual faces for Hyper-V, in this way, the same secondary storage will be able to serve XenServer/VMware/KVM/Hyper-V within the same zone.

We do have a Hyper-V prototype in current CloudStack code base, you may also want to check it out before you start.

Kelven


-----Original Message-----
From: Alessandro Pilotti [mailto:ap@pilotti.it] 
Sent: Saturday, April 21, 2012 1:35 PM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: Re: [cloudstack-devel] Hyper-V Support

I started looking into the code for VMWare and KVM resources in order to develop the Hyper-V Resource, the proxy based architecture is clear.


I have some basic questions to start with :-)

1) I'm looking at the commands in com.cloud.agent.api. Is there some documentation? To start coding the HyperV adapter, is there a list of mandatory and optional commands? I'm "reverse engineering" their semantyc looking at the VMWare resources, but it's not so trivial :)

2) Commands are synchronous or asynchronous? In case how do you handle running jobs?

3) Configuration: how do I tell CS that a new HyperVisor Resource type exists? (both cases: Manager based / Agent based)

4) Storage: the free Hyper-V server does not contain an NFS client. There are of course open source NFS clients (Cygwin, etc) that can be installed, but supporting SMB might be easier. What do you think about adding support for SMB shares in CS?  



Thanks!

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

Re: [cloudstack-devel] Hyper-V Support

[Alessandro Pilotti <ap...@pilotti.it>]

I started looking into the code for VMWare and KVM resources in order to develop the Hyper-V Resource, the proxy based architecture is clear.


I have some basic questions to start with :-)

1) I'm looking at the commands in com.cloud.agent.api. Is there some documentation? To start coding the HyperV adapter, is there a list of mandatory and optional commands? I'm "reverse engineering" their semantyc looking at the VMWare resources, but it's not so trivial :)

2) Commands are synchronous or asynchronous? In case how do you handle running jobs?

3) Configuration: how do I tell CS that a new HyperVisor Resource type exists? (both cases: Manager based / Agent based)

4) Storage: the free Hyper-V server does not contain an NFS client. There are of course open source NFS clients (Cygwin, etc) that can be installed, but supporting SMB might be easier. What do you think about adding support for SMB shares in CS?  



Thanks!

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

RE: [cloudstack-devel] Hyper-V Support

[Kelven Yang <ke...@citrix.com>]

Alessandro,

About Integrating Hyper-V into CloudStack, the first question you might want to answer is that where the integration point happens. In KVM/XenServer, CloudStack directly orchestrates hypervisor hosts, particularly, in KVM case we deploy an on-site agent running on host. In XenServer case, CloudStack communicates with host via XS XMLRPC API, we also have host plugin at XS dom0 for things that its XMLRPC API is lack of doing. However in VMware case, the integration point happens at vCenter, means that we don't directly communicate hypervisor hosts and neither have any pluggable components on them.

Back to Hyper-V, are you going to take advantage of SCVMM and integrate CloudStack through SCVMM? Or you want to directly orchestrate Hyper-V hosts? It matters from architecture perspective.

Kelven



-----Original Message-----
From: Frank Zhang [mailto:Frank.Zhang@citrix.com] 
Sent: Friday, April 20, 2012 10:20 AM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: RE: [cloudstack-devel] Hyper-V Support

>>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?
We use basic authentication of XmlRpc, each time Resource that works as a XmlRpc client connects to Agent that works as a XmlRpc server, account/password is required.

-----Original Message-----
From: Alessandro Pilotti [mailto:ap@pilotti.it] 
Sent: Friday, April 20, 2012 4:39 AM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: Re: [cloudstack-devel] Hyper-V Support

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

Re: Security aspects of CloudStack console access

[Alex Karasulu <ak...@apache.org>]

On Sat, Apr 21, 2012 at 9:40 PM, Kelven Yang <ke...@citrix.com> wrote:

> Token issuing process here does look similar with Kerberos ticket issuing
> process, however, the access token we issue in CloudStack management server
> not only contains  authentication information alone, but also other
> information that is essential to contact to the hypervisor VNC server. For
> all the involved parties, management server, console service VMs and
> hypervisor hosts, not all of them can freely participate  Kerberos session.
> Balance it with the goal of just securing access-info in URL and the
> complexity of Kerberos deployment brought into the picture, we haven't
> looked into it.
>
>
>
Understood. Thanks for the background Kelven.


> -----Original Message-----
> From: akarasulu@gmail.com [mailto:akarasulu@gmail.com] On Behalf Of Alex
> Karasulu
> Sent: Saturday, April 21, 2012 2:02 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Security aspects of CloudStack console access
>
> On Sat, Apr 21, 2012 at 6:45 AM, Kelven Yang <ke...@citrix.com>
> wrote:
>
> > Access token is exactly another added layer, the first security layer is
> > provided through HTTPS web session. Second layer is the dynamic access
> > token, third-layer is the timely expiration of access token.
> >
> >
> The flow and use cases I'm seeing here seems ideal for a Kerberos solution.
> Were there any thoughts along these lines for some of these security
> issues?
>
>
> > -----Original Message-----
> > From: John Kinsella [mailto:jlk@stratosec.co]
> > Sent: Friday, April 20, 2012 6:48 PM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: Development discussions for CloudStack
> > Subject: Re: Security aspects of CloudStack console access
> >
> > I understand you're limited by VNC's setup, but DES is considered a
> > "broken" crypto algorithm, and it'd be in our best interests to get
> > something stronger in place in the future...I'll probably offer customers
> > VNC over VPN.
> >
> > And regarding SSL, that too is more or less crippled. Security needs to
> > take a layered approach, so that if one layer is compromised (see:
> > malicious organizations being issued CA certs and therefore the ability
> to
> > create any SSL cert they want) other layers will still prevent malicious
> > use.
> >
> > John
> >
> > On Apr 20, 2012, at 5:58 PM, Kelven Yang wrote:
> >
> > > From time to time, we received a number of emails from security experts
> > who want to raise concerns about accessing the guest console. We've
> > listened and started to address these security concerns in upcoming
> > releases. I'd like to throw a brief introduction in this area and would
> > like to gather feedbacks from CloudStack development community.
> > >
> > > 1. Design principal of CloudStack console access service
> > >
> > >   a) Separate control path and data path
> > >       CloudStack Management server manages control traffic, console
> > service VMs manage data (access) traffic. Which means that as soon as
> > CloudStack management server has helped setup the access session, it will
> > go out of the picture. A access session will be solely conducted within a
> > console service VM from then on.
> > >
> > >   b) Console service VM is stateless
> > >       Console service VM works in stateless mode, this is to allow an
> > easy scale-out solution. CloudStack management server will automatically
> > launch necessary service VMs based on current system load. A stateless
> > service VM leads to the design of having management server to help
> > negotiate, authenticate and setup the access session.
> > >
> > > 2. How it works
> > > To start a console access session, management server first generates an
> > access token, assigns a service VM instance, and then redirects client
> > browser (in a new window) to initiate the session to the target service
> VM
> > with the access token.
> > >
> > > When service VM receives the access request, it relays the
> > authentication request to management server presenting the token passed
> > from client browser. At this phase, if management service is running as a
> > CloudStack management server cluster, the request may be relayed to a
> > different management server instance other than where the original token
> > was generated on.
> > >
> > > If the request can be authenticated successfully, an access session
> will
> > be open in the service VM. After this point, user will be able to access
> > the guest VM via a AJAX viewer sent from the service VM to client
> browser.
> > >
> > > 3. Security aspects
> > >       a) Passing access token.
> > >       We originally rely on management server secured web session to
> > protect the access info, the access info appears in clear text in browser
> > url. A lot of people have raised concerns of this. To address the
> concern,
> > we now wrap the access information into an DES encrypted access token,
> DES
> > encryption key is randomly generated at per CloudStack installation
> basis.
> > The DES encryption key will also be passed to console service VM via our
> > SSL-enabled agent/management server channel so that service VM would be
> > able to continue performing security validation after management server
> has
> > gone out of the picture.
> > >
> > > Access token is also time-stamped by management server. Session
> > authentication should happen within the time period, otherwise, access
> will
> > be declined. If management service is running as a management server
> > cluster, all management server instances have to be time-synced.
> > >
> > >       b) Securely access to hypervisor VNC sessions
> > >       We recently added support to use XenServer secure access API to
> > secure the traffic between console service VM and XenServer host. For
> > KVM/VMware, a random generated hypervisor password will be included
> inside
> > the access token, console service VM uses the information to setup the
> > security within the VNC protocol framework.
> > >
> > > I hope I have done a good explanation work, if you do have further
> > security concerns, please feel free to drop your feedback on this to the
> > list.
> > >
> > > Kelven
> > >
> >
> > Stratosec - Secure Infrastructure as a Service
> > o: 415.315.9385
> > @johnlkinsella
> >
> >
>
>
> --
> Best Regards,
> -- Alex
>



-- 
Best Regards,
-- Alex

RE: Security aspects of CloudStack console access

[Kelven Yang <ke...@citrix.com>]

Token issuing process here does look similar with Kerberos ticket issuing process, however, the access token we issue in CloudStack management server not only contains  authentication information alone, but also other information that is essential to contact to the hypervisor VNC server. For all the involved parties, management server, console service VMs and hypervisor hosts, not all of them can freely participate  Kerberos session. Balance it with the goal of just securing access-info in URL and the complexity of Kerberos deployment brought into the picture, we haven't looked into it.

Kelven


-----Original Message-----
From: akarasulu@gmail.com [mailto:akarasulu@gmail.com] On Behalf Of Alex Karasulu
Sent: Saturday, April 21, 2012 2:02 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Security aspects of CloudStack console access

On Sat, Apr 21, 2012 at 6:45 AM, Kelven Yang <ke...@citrix.com> wrote:

> Access token is exactly another added layer, the first security layer is
> provided through HTTPS web session. Second layer is the dynamic access
> token, third-layer is the timely expiration of access token.
>
>
The flow and use cases I'm seeing here seems ideal for a Kerberos solution.
Were there any thoughts along these lines for some of these security issues?


> -----Original Message-----
> From: John Kinsella [mailto:jlk@stratosec.co]
> Sent: Friday, April 20, 2012 6:48 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Development discussions for CloudStack
> Subject: Re: Security aspects of CloudStack console access
>
> I understand you're limited by VNC's setup, but DES is considered a
> "broken" crypto algorithm, and it'd be in our best interests to get
> something stronger in place in the future...I'll probably offer customers
> VNC over VPN.
>
> And regarding SSL, that too is more or less crippled. Security needs to
> take a layered approach, so that if one layer is compromised (see:
> malicious organizations being issued CA certs and therefore the ability to
> create any SSL cert they want) other layers will still prevent malicious
> use.
>
> John
>
> On Apr 20, 2012, at 5:58 PM, Kelven Yang wrote:
>
> > From time to time, we received a number of emails from security experts
> who want to raise concerns about accessing the guest console. We've
> listened and started to address these security concerns in upcoming
> releases. I'd like to throw a brief introduction in this area and would
> like to gather feedbacks from CloudStack development community.
> >
> > 1. Design principal of CloudStack console access service
> >
> >   a) Separate control path and data path
> >       CloudStack Management server manages control traffic, console
> service VMs manage data (access) traffic. Which means that as soon as
> CloudStack management server has helped setup the access session, it will
> go out of the picture. A access session will be solely conducted within a
> console service VM from then on.
> >
> >   b) Console service VM is stateless
> >       Console service VM works in stateless mode, this is to allow an
> easy scale-out solution. CloudStack management server will automatically
> launch necessary service VMs based on current system load. A stateless
> service VM leads to the design of having management server to help
> negotiate, authenticate and setup the access session.
> >
> > 2. How it works
> > To start a console access session, management server first generates an
> access token, assigns a service VM instance, and then redirects client
> browser (in a new window) to initiate the session to the target service VM
> with the access token.
> >
> > When service VM receives the access request, it relays the
> authentication request to management server presenting the token passed
> from client browser. At this phase, if management service is running as a
> CloudStack management server cluster, the request may be relayed to a
> different management server instance other than where the original token
> was generated on.
> >
> > If the request can be authenticated successfully, an access session will
> be open in the service VM. After this point, user will be able to access
> the guest VM via a AJAX viewer sent from the service VM to client browser.
> >
> > 3. Security aspects
> >       a) Passing access token.
> >       We originally rely on management server secured web session to
> protect the access info, the access info appears in clear text in browser
> url. A lot of people have raised concerns of this. To address the concern,
> we now wrap the access information into an DES encrypted access token, DES
> encryption key is randomly generated at per CloudStack installation basis.
> The DES encryption key will also be passed to console service VM via our
> SSL-enabled agent/management server channel so that service VM would be
> able to continue performing security validation after management server has
> gone out of the picture.
> >
> > Access token is also time-stamped by management server. Session
> authentication should happen within the time period, otherwise, access will
> be declined. If management service is running as a management server
> cluster, all management server instances have to be time-synced.
> >
> >       b) Securely access to hypervisor VNC sessions
> >       We recently added support to use XenServer secure access API to
> secure the traffic between console service VM and XenServer host. For
> KVM/VMware, a random generated hypervisor password will be included inside
> the access token, console service VM uses the information to setup the
> security within the VNC protocol framework.
> >
> > I hope I have done a good explanation work, if you do have further
> security concerns, please feel free to drop your feedback on this to the
> list.
> >
> > Kelven
> >
>
> Stratosec - Secure Infrastructure as a Service
> o: 415.315.9385
> @johnlkinsella
>
>


-- 
Best Regards,
-- Alex

Re: Security aspects of CloudStack console access

[Alex Karasulu <ak...@apache.org>]

On Sat, Apr 21, 2012 at 6:45 AM, Kelven Yang <ke...@citrix.com> wrote:

> Access token is exactly another added layer, the first security layer is
> provided through HTTPS web session. Second layer is the dynamic access
> token, third-layer is the timely expiration of access token.
>
>
The flow and use cases I'm seeing here seems ideal for a Kerberos solution.
Were there any thoughts along these lines for some of these security issues?


> -----Original Message-----
> From: John Kinsella [mailto:jlk@stratosec.co]
> Sent: Friday, April 20, 2012 6:48 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Development discussions for CloudStack
> Subject: Re: Security aspects of CloudStack console access
>
> I understand you're limited by VNC's setup, but DES is considered a
> "broken" crypto algorithm, and it'd be in our best interests to get
> something stronger in place in the future...I'll probably offer customers
> VNC over VPN.
>
> And regarding SSL, that too is more or less crippled. Security needs to
> take a layered approach, so that if one layer is compromised (see:
> malicious organizations being issued CA certs and therefore the ability to
> create any SSL cert they want) other layers will still prevent malicious
> use.
>
> John
>
> On Apr 20, 2012, at 5:58 PM, Kelven Yang wrote:
>
> > From time to time, we received a number of emails from security experts
> who want to raise concerns about accessing the guest console. We've
> listened and started to address these security concerns in upcoming
> releases. I'd like to throw a brief introduction in this area and would
> like to gather feedbacks from CloudStack development community.
> >
> > 1. Design principal of CloudStack console access service
> >
> >   a) Separate control path and data path
> >       CloudStack Management server manages control traffic, console
> service VMs manage data (access) traffic. Which means that as soon as
> CloudStack management server has helped setup the access session, it will
> go out of the picture. A access session will be solely conducted within a
> console service VM from then on.
> >
> >   b) Console service VM is stateless
> >       Console service VM works in stateless mode, this is to allow an
> easy scale-out solution. CloudStack management server will automatically
> launch necessary service VMs based on current system load. A stateless
> service VM leads to the design of having management server to help
> negotiate, authenticate and setup the access session.
> >
> > 2. How it works
> > To start a console access session, management server first generates an
> access token, assigns a service VM instance, and then redirects client
> browser (in a new window) to initiate the session to the target service VM
> with the access token.
> >
> > When service VM receives the access request, it relays the
> authentication request to management server presenting the token passed
> from client browser. At this phase, if management service is running as a
> CloudStack management server cluster, the request may be relayed to a
> different management server instance other than where the original token
> was generated on.
> >
> > If the request can be authenticated successfully, an access session will
> be open in the service VM. After this point, user will be able to access
> the guest VM via a AJAX viewer sent from the service VM to client browser.
> >
> > 3. Security aspects
> >       a) Passing access token.
> >       We originally rely on management server secured web session to
> protect the access info, the access info appears in clear text in browser
> url. A lot of people have raised concerns of this. To address the concern,
> we now wrap the access information into an DES encrypted access token, DES
> encryption key is randomly generated at per CloudStack installation basis.
> The DES encryption key will also be passed to console service VM via our
> SSL-enabled agent/management server channel so that service VM would be
> able to continue performing security validation after management server has
> gone out of the picture.
> >
> > Access token is also time-stamped by management server. Session
> authentication should happen within the time period, otherwise, access will
> be declined. If management service is running as a management server
> cluster, all management server instances have to be time-synced.
> >
> >       b) Securely access to hypervisor VNC sessions
> >       We recently added support to use XenServer secure access API to
> secure the traffic between console service VM and XenServer host. For
> KVM/VMware, a random generated hypervisor password will be included inside
> the access token, console service VM uses the information to setup the
> security within the VNC protocol framework.
> >
> > I hope I have done a good explanation work, if you do have further
> security concerns, please feel free to drop your feedback on this to the
> list.
> >
> > Kelven
> >
>
> Stratosec - Secure Infrastructure as a Service
> o: 415.315.9385
> @johnlkinsella
>
>


-- 
Best Regards,
-- Alex

RE: Security aspects of CloudStack console access

[Kelven Yang <ke...@citrix.com>]

Access token is exactly another added layer, the first security layer is provided through HTTPS web session. Second layer is the dynamic access token, third-layer is the timely expiration of access token.

As we already have the first layer of security, using DES to protect the access token is mainly for performance consideration, AJAX + web pulling has already slowed down the responding time a lot, we don't want to go to the extreme on security to sacrifice performance too much.

Kelven

-----Original Message-----
From: John Kinsella [mailto:jlk@stratosec.co] 
Sent: Friday, April 20, 2012 6:48 PM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: Re: Security aspects of CloudStack console access

I understand you're limited by VNC's setup, but DES is considered a "broken" crypto algorithm, and it'd be in our best interests to get something stronger in place in the future...I'll probably offer customers VNC over VPN.

And regarding SSL, that too is more or less crippled. Security needs to take a layered approach, so that if one layer is compromised (see: malicious organizations being issued CA certs and therefore the ability to create any SSL cert they want) other layers will still prevent malicious use.

John

On Apr 20, 2012, at 5:58 PM, Kelven Yang wrote:

> From time to time, we received a number of emails from security experts who want to raise concerns about accessing the guest console. We've listened and started to address these security concerns in upcoming releases. I'd like to throw a brief introduction in this area and would like to gather feedbacks from CloudStack development community.
> 
> 1. Design principal of CloudStack console access service
> 
>   a) Separate control path and data path
> 	CloudStack Management server manages control traffic, console service VMs manage data (access) traffic. Which means that as soon as CloudStack management server has helped setup the access session, it will go out of the picture. A access session will be solely conducted within a console service VM from then on.
> 
>   b) Console service VM is stateless
> 	Console service VM works in stateless mode, this is to allow an easy scale-out solution. CloudStack management server will automatically launch necessary service VMs based on current system load. A stateless service VM leads to the design of having management server to help negotiate, authenticate and setup the access session.
> 
> 2. How it works
> To start a console access session, management server first generates an access token, assigns a service VM instance, and then redirects client browser (in a new window) to initiate the session to the target service VM with the access token.
> 
> When service VM receives the access request, it relays the authentication request to management server presenting the token passed from client browser. At this phase, if management service is running as a CloudStack management server cluster, the request may be relayed to a different management server instance other than where the original token was generated on.
> 
> If the request can be authenticated successfully, an access session will be open in the service VM. After this point, user will be able to access the guest VM via a AJAX viewer sent from the service VM to client browser.
> 
> 3. Security aspects
> 	a) Passing access token.
> 	We originally rely on management server secured web session to protect the access info, the access info appears in clear text in browser url. A lot of people have raised concerns of this. To address the concern, we now wrap the access information into an DES encrypted access token, DES encryption key is randomly generated at per CloudStack installation basis. The DES encryption key will also be passed to console service VM via our SSL-enabled agent/management server channel so that service VM would be able to continue performing security validation after management server has gone out of the picture.
> 
> Access token is also time-stamped by management server. Session authentication should happen within the time period, otherwise, access will be declined. If management service is running as a management server cluster, all management server instances have to be time-synced.
> 
> 	b) Securely access to hypervisor VNC sessions
> 	We recently added support to use XenServer secure access API to secure the traffic between console service VM and XenServer host. For KVM/VMware, a random generated hypervisor password will be included inside the access token, console service VM uses the information to setup the security within the VNC protocol framework.
> 
> I hope I have done a good explanation work, if you do have further security concerns, please feel free to drop your feedback on this to the list.
> 
> Kelven
> 

Stratosec - Secure Infrastructure as a Service
o: 415.315.9385
@johnlkinsella

Re: Security aspects of CloudStack console access

[John Kinsella <jl...@stratosec.co>]

I understand you're limited by VNC's setup, but DES is considered a "broken" crypto algorithm, and it'd be in our best interests to get something stronger in place in the future...I'll probably offer customers VNC over VPN.

And regarding SSL, that too is more or less crippled. Security needs to take a layered approach, so that if one layer is compromised (see: malicious organizations being issued CA certs and therefore the ability to create any SSL cert they want) other layers will still prevent malicious use.

John

On Apr 20, 2012, at 5:58 PM, Kelven Yang wrote:

> From time to time, we received a number of emails from security experts who want to raise concerns about accessing the guest console. We've listened and started to address these security concerns in upcoming releases. I'd like to throw a brief introduction in this area and would like to gather feedbacks from CloudStack development community.
> 
> 1. Design principal of CloudStack console access service
> 
>   a) Separate control path and data path
> 	CloudStack Management server manages control traffic, console service VMs manage data (access) traffic. Which means that as soon as CloudStack management server has helped setup the access session, it will go out of the picture. A access session will be solely conducted within a console service VM from then on.
> 
>   b) Console service VM is stateless
> 	Console service VM works in stateless mode, this is to allow an easy scale-out solution. CloudStack management server will automatically launch necessary service VMs based on current system load. A stateless service VM leads to the design of having management server to help negotiate, authenticate and setup the access session.
> 
> 2. How it works
> To start a console access session, management server first generates an access token, assigns a service VM instance, and then redirects client browser (in a new window) to initiate the session to the target service VM with the access token.
> 
> When service VM receives the access request, it relays the authentication request to management server presenting the token passed from client browser. At this phase, if management service is running as a CloudStack management server cluster, the request may be relayed to a different management server instance other than where the original token was generated on.
> 
> If the request can be authenticated successfully, an access session will be open in the service VM. After this point, user will be able to access the guest VM via a AJAX viewer sent from the service VM to client browser.
> 
> 3. Security aspects
> 	a) Passing access token.
> 	We originally rely on management server secured web session to protect the access info, the access info appears in clear text in browser url. A lot of people have raised concerns of this. To address the concern, we now wrap the access information into an DES encrypted access token, DES encryption key is randomly generated at per CloudStack installation basis. The DES encryption key will also be passed to console service VM via our SSL-enabled agent/management server channel so that service VM would be able to continue performing security validation after management server has gone out of the picture.
> 
> Access token is also time-stamped by management server. Session authentication should happen within the time period, otherwise, access will be declined. If management service is running as a management server cluster, all management server instances have to be time-synced.
> 
> 	b) Securely access to hypervisor VNC sessions
> 	We recently added support to use XenServer secure access API to secure the traffic between console service VM and XenServer host. For KVM/VMware, a random generated hypervisor password will be included inside the access token, console service VM uses the information to setup the security within the VNC protocol framework.
> 
> I hope I have done a good explanation work, if you do have further security concerns, please feel free to drop your feedback on this to the list.
> 
> Kelven
> 

Stratosec - Secure Infrastructure as a Service
o: 415.315.9385
@johnlkinsella

RE: Security aspects of CloudStack console access

[Will Chan <wi...@citrix.com>]

You should also add this to the wiki.

________________________________________
From: Kelven Yang [kelven.yang@citrix.com]
Sent: Friday, April 20, 2012 5:58 PM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: Security aspects of CloudStack console access

>From time to time, we received a number of emails from security experts who want to raise concerns about accessing the guest console. We've listened and started to address these security concerns in upcoming releases. I'd like to throw a brief introduction in this area and would like to gather feedbacks from CloudStack development community.

1. Design principal of CloudStack console access service

   a) Separate control path and data path
        CloudStack Management server manages control traffic, console service VMs manage data (access) traffic. Which means that as soon as CloudStack management server has helped setup the access session, it will go out of the picture. A access session will be solely conducted within a console service VM from then on.

   b) Console service VM is stateless
        Console service VM works in stateless mode, this is to allow an easy scale-out solution. CloudStack management server will automatically launch necessary service VMs based on current system load. A stateless service VM leads to the design of having management server to help negotiate, authenticate and setup the access session.

2. How it works
To start a console access session, management server first generates an access token, assigns a service VM instance, and then redirects client browser (in a new window) to initiate the session to the target service VM with the access token.

When service VM receives the access request, it relays the authentication request to management server presenting the token passed from client browser. At this phase, if management service is running as a CloudStack management server cluster, the request may be relayed to a different management server instance other than where the original token was generated on.

If the request can be authenticated successfully, an access session will be open in the service VM. After this point, user will be able to access the guest VM via a AJAX viewer sent from the service VM to client browser.

3. Security aspects
        a) Passing access token.
        We originally rely on management server secured web session to protect the access info, the access info appears in clear text in browser url. A lot of people have raised concerns of this. To address the concern, we now wrap the access information into an DES encrypted access token, DES encryption key is randomly generated at per CloudStack installation basis. The DES encryption key will also be passed to console service VM via our SSL-enabled agent/management server channel so that service VM would be able to continue performing security validation after management server has gone out of the picture.

Access token is also time-stamped by management server. Session authentication should happen within the time period, otherwise, access will be declined. If management service is running as a management server cluster, all management server instances have to be time-synced.

        b) Securely access to hypervisor VNC sessions
        We recently added support to use XenServer secure access API to secure the traffic between console service VM and XenServer host. For KVM/VMware, a random generated hypervisor password will be included inside the access token, console service VM uses the information to setup the security within the VNC protocol framework.

I hope I have done a good explanation work, if you do have further security concerns, please feel free to drop your feedback on this to the list.

Kelven

RE: Security aspects of CloudStack console access

[Kelven Yang <ke...@citrix.com>]

It is hard-coded to 2 minutes. We assume from the time that management has generated the token, browser should be able to start a session within this time period. It also means that if someone has already broken our first layer (HTTPS web session) of security, he/she has up to 2 minutes to break 64-bit keyed DES access token. Not sure if it is strong enough though, I'm looking forward to hearing from security experts in the community to comment on that.

Kelven

-----Original Message-----
From: David Nalley [mailto:david@gnsa.us] 
Sent: Friday, April 20, 2012 6:48 PM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: Re: Security aspects of CloudStack console access

On Fri, Apr 20, 2012 at 9:36 PM, Kelven Yang <ke...@citrix.com> wrote:
>>> This is done by the expiration argument to the API call to setup the
> session?
> No, the expiration time is not set through API parameter, but generated directly within management server. We don't want this to be configurable.
>

So it's hardcoded? What length of time is it set to?

--David

Re: Security aspects of CloudStack console access

[David Nalley <da...@gnsa.us>]

On Fri, Apr 20, 2012 at 9:36 PM, Kelven Yang <ke...@citrix.com> wrote:
>>> This is done by the expiration argument to the API call to setup the
> session?
> No, the expiration time is not set through API parameter, but generated directly within management server. We don't want this to be configurable.
>

So it's hardcoded? What length of time is it set to?

--David

RE: Security aspects of CloudStack console access

[Kelven Yang <ke...@citrix.com>]

>> The issue was that we were shipping the default configuration sans SSL
enabled, but expecting that folks who cared about security would
enable SSL?

Even if SSL is enabled for management server, some people are still allergic to see clear text in the URL that carries console access information in clear text.

>> This token is different from the auth token that is generated from the
login call right? 
Right, this token is different from auth token from Apache Tomcat or API keys in CloudStack API

>> Unique to each console session (e.g. if I opened a
session on the same VM twice, I'd get two tokens?)

Yes, unique to each console session

>> This is done by the expiration argument to the API call to setup the
session?
No, the expiration time is not set through API parameter, but generated directly within management server. We don't want this to be configurable.

This is also not the same as you mentioned about "I know we talked about adding that expiration value as part of the 3.0.0 release".

Kelven

-----Original Message-----
From: David Nalley [mailto:david@gnsa.us] 
Sent: Friday, April 20, 2012 6:24 PM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: Re: Security aspects of CloudStack console access

To make sure that I understand this.....

On Fri, Apr 20, 2012 at 8:58 PM, Kelven Yang <ke...@citrix.com> wrote:

>        a) Passing access token.
>        We originally rely on management server secured web session to protect the access info, the access info appears in clear text in browser url. A lot of people have raised concerns of this. To address the concern, we now wrap the access information into an DES encrypted access token, DES encryption key is randomly generated at per CloudStack installation basis. The DES encryption key will also be passed to console service VM via our SSL-enabled agent/management server channel so that service VM would be able to continue performing security validation after management server has gone out of the picture.

The issue was that we were shipping the default configuration sans SSL
enabled, but expecting that folks who cared about security would
enable SSL?
This token is different from the auth token that is generated from the
login call right? Unique to each console session (e.g. if I opened a
session on the same VM twice, I'd get two tokens?)

>
> Access token is also time-stamped by management server. Session authentication should happen within the time period, otherwise, access will be declined. If management service is running as a management server cluster, all management server instances have to be time-synced.

This is done by the expiration argument to the API call to setup the
session? Speaking of, I know we talked about adding that expiration
value as part of the 3.0.0 release, but I can't find any reference to
it in the API docs, Release Notes, or the API developers guide.

Re: Security aspects of CloudStack console access

[David Nalley <da...@gnsa.us>]

To make sure that I understand this.....

On Fri, Apr 20, 2012 at 8:58 PM, Kelven Yang <ke...@citrix.com> wrote:

>        a) Passing access token.
>        We originally rely on management server secured web session to protect the access info, the access info appears in clear text in browser url. A lot of people have raised concerns of this. To address the concern, we now wrap the access information into an DES encrypted access token, DES encryption key is randomly generated at per CloudStack installation basis. The DES encryption key will also be passed to console service VM via our SSL-enabled agent/management server channel so that service VM would be able to continue performing security validation after management server has gone out of the picture.

The issue was that we were shipping the default configuration sans SSL
enabled, but expecting that folks who cared about security would
enable SSL?
This token is different from the auth token that is generated from the
login call right? Unique to each console session (e.g. if I opened a
session on the same VM twice, I'd get two tokens?)

>
> Access token is also time-stamped by management server. Session authentication should happen within the time period, otherwise, access will be declined. If management service is running as a management server cluster, all management server instances have to be time-synced.

This is done by the expiration argument to the API call to setup the
session? Speaking of, I know we talked about adding that expiration
value as part of the 3.0.0 release, but I can't find any reference to
it in the API docs, Release Notes, or the API developers guide.

Security aspects of CloudStack console access

[Kelven Yang <ke...@citrix.com>]

>From time to time, we received a number of emails from security experts who want to raise concerns about accessing the guest console. We've listened and started to address these security concerns in upcoming releases. I'd like to throw a brief introduction in this area and would like to gather feedbacks from CloudStack development community.

1. Design principal of CloudStack console access service

   a) Separate control path and data path
	CloudStack Management server manages control traffic, console service VMs manage data (access) traffic. Which means that as soon as CloudStack management server has helped setup the access session, it will go out of the picture. A access session will be solely conducted within a console service VM from then on.

   b) Console service VM is stateless
	Console service VM works in stateless mode, this is to allow an easy scale-out solution. CloudStack management server will automatically launch necessary service VMs based on current system load. A stateless service VM leads to the design of having management server to help negotiate, authenticate and setup the access session.

2. How it works
To start a console access session, management server first generates an access token, assigns a service VM instance, and then redirects client browser (in a new window) to initiate the session to the target service VM with the access token.

When service VM receives the access request, it relays the authentication request to management server presenting the token passed from client browser. At this phase, if management service is running as a CloudStack management server cluster, the request may be relayed to a different management server instance other than where the original token was generated on.

If the request can be authenticated successfully, an access session will be open in the service VM. After this point, user will be able to access the guest VM via a AJAX viewer sent from the service VM to client browser.

3. Security aspects
	a) Passing access token.
	We originally rely on management server secured web session to protect the access info, the access info appears in clear text in browser url. A lot of people have raised concerns of this. To address the concern, we now wrap the access information into an DES encrypted access token, DES encryption key is randomly generated at per CloudStack installation basis. The DES encryption key will also be passed to console service VM via our SSL-enabled agent/management server channel so that service VM would be able to continue performing security validation after management server has gone out of the picture.

Access token is also time-stamped by management server. Session authentication should happen within the time period, otherwise, access will be declined. If management service is running as a management server cluster, all management server instances have to be time-synced.

	b) Securely access to hypervisor VNC sessions
	We recently added support to use XenServer secure access API to secure the traffic between console service VM and XenServer host. For KVM/VMware, a random generated hypervisor password will be included inside the access token, console service VM uses the information to setup the security within the VNC protocol framework.

I hope I have done a good explanation work, if you do have further security concerns, please feel free to drop your feedback on this to the list.

Kelven

RE: [cloudstack-devel] Hyper-V Support

[Frank Zhang <Fr...@citrix.com>]

>>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?
We use basic authentication of XmlRpc, each time Resource that works as a XmlRpc client connects to Agent that works as a XmlRpc server, account/password is required.

-----Original Message-----
From: Alessandro Pilotti [mailto:ap@pilotti.it] 
Sent: Friday, April 20, 2012 4:39 AM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: Re: [cloudstack-devel] Hyper-V Support

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

Re: [cloudstack-devel] Hyper-V Support

[Alessandro Pilotti <ap...@pilotti.it>]

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