incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <>
Subject RE: pluggable storage implementation
Date Mon, 10 Dec 2012 20:31:19 GMT
KVMStoragePoolManager should manage the mapping between storage pool type and storageadaptor.

1.  In KVMStoragePoolManager's constructor, create a map between storage pool type and storageadaptor:
sample code:
map<String, storageadaptor> storageMapper = new HashMap<String, storageadaptor>();
storageMapper.add("your-storage-type", new your-storage-adaptor);
storageMapper.add("libvirt-managed-storage", new LibvirtStorageAdaptor);

2.  For each api of KVMStoragePoolManager, should pass down a storage pool type, e.g:

public KVMStoragePool getStoragePool(String storagePoolType, String uuid) {

       storageadaptor adaptor = storageMapper.get(storagepoolType);

       if (adaptor == null) {

              adaptor = storageMapper.get("libvirt-managed-storage");


return adaptor.getStoragePool(uuid);


From: Marcus Sorensen []
Sent: Monday, December 10, 2012 3:06 PM
To: Edison Su
Subject: Re: pluggable storage implementation

Yeah, but I'm not seeing an easy/pluggable way to implement a storage adaptor, where LibvirtComputingResource
relies exclusively on KVMStoragePoolManager, which is implementing LibvirtStorageAdaptor.
I don't see how to switch between storage adaptors in based on
what primary storage type I happen to be acting upon.

On Mon, Dec 10, 2012 at 12:51 PM, Edison Su <<>>

From: Marcus Sorensen [<>]
Sent: Monday, December 10, 2012 2:06 PM
To: Edison Su
Subject: pluggable storage implementation

Just curious, hadn't thought about this before but it seems that at least on KVM (probably
similar in Xen and VMware too?), there are two separate issues with storage in the existing
code. First, adding a new storage type is a matter of adding in a new 'else if' or something
in a bunch of different places, as well as tweaking behavior to match the storage type. Second,
everything about the storage is tightly integrated with Libvirt, meaning that if your storage
type is not supported by Libvirt it's much, much more difficult to implement.

Are these both being addressed by the storage changes, for example can we write a storage
plugin that creates pools/volumes that libvirt doesn't know about and still attach those to
instances? Or would we need to patch libvirt to utilize our storage first?

[Edison] That's the storageadaptor used for:;a=blob;f=plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/;h=ef1e7c9302ab6ac8f197cf75bbf7235bba0235cf;hb=HEAD
The LibvirtStorageAdaptor  is one of implementation of storageadaptor, which is totally based
on libvirt, If you have a new storage, not supported by libvirt, then you can add a new implementation
of storageadaptor.

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