cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <>
Subject RE: new storage framework update
Date Wed, 16 Jan 2013 04:39:10 GMT
I'm interested in this.  Please add me to whatever medium you guys are using.


> -----Original Message-----
> From: David Nalley []
> Sent: Tuesday, January 15, 2013 7:09 PM
> To:
> Subject: Re: new storage framework update
> On Tue, Jan 15, 2013 at 8:35 PM, Edison Su <> wrote:
> > After a lengthy discussion(more than two hours) with John on Skype, I
> think we figured out the difference between us.  The API proposed by John
> is more at the execution level, that's where input/output stream coming
> from, which assumes that both source and destination object will be
> operated at the same place(either inside ssvm, or on hypervisor host). While
> the API I proposed is more about how to hook up vendor's own storage into
> cloudstack's mgt server, thus can replace the process on how and where to
> operate on the storage.
> > Let's talk about the execution model at first, which will have huge impact
> on the design we made. The execution model is about where to execute
> operations issued by mgt server. Currently, there is no universal execution
> model, it's quite different for each hypervisor.
> >  E.g. for KVM, mgt server will send commands to KVM host, there is a java
> agent running on kvm host, which can execute command send by mgt server.
> > For xenserver, most of commands will be executed on mgt server, which
> will call xapi, then talking to xenserver host.  But we do put some python
> code at xenserver host, if there are operations not supported by xapi.
> > For vmware, most of commands will be executed on mgt server, which
> talking to vcenter API, while some of them will be executed inside SSVM.
> > Due to the different execution models, we'll get into a problem about how
> and where to access storage device. For example, there is a storage box,
> which has its own management API to be accessed. Now I want to create a
> volume on the storage box, where should I call stoage box's create volume
> api? If we follow up above execution models, we need to call the api at
> different places and even worse, you need to write the API call in different
> languages. For kvm, you may need to write java code in kvm agent, for
> xenserver, you may need to write a xapi python plugin, for vmware, you may
> need to put the java code inside ssvm  etc.
> > But if the storage box already has management api, why just call it inside
> cloudstack mgt server, then device vendor should just write java code once,
> for all the different hypervisors? If we don't enforce the execution model,
> then the storage framework should have a hook in management server,
> device vendor can decide where to execute commands send by mgt server.
> > That's my datastoredriver layer used for. Take taking snapshot diagram as
> an example:
> +snapshot+sequence.png?version=1&modificationDate=1358189965000
> > Datastoredriver is running inside mgt server, while datastoredriver itself
> can decide where to execute "takasnapshot" API, driver can send a
> command to hypervisor host, or directly call storage box's API, or directly call
> hypervisor's own API, or another service running outside of cloudstack mgt
> server. It's all up to the implementation of driver.
> > Does it make sense? If it's true, the device driver should not take input/out
> stream as parameter, as it enforces the execution model, which I don't think
> it's necessary.
> > BTW, John and I will discuss the matter tomorrow on Skype, if you want to
> join, please let me know.
> >
> Is this text conversation on Skype? If so, why not do this on IRC in
> -meeting or -dev? We can log it all and have more people join.
> --David

View raw message