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 [mailto:[email protected]]
Sent: Monday, December 10, 2012 3:06 PM
To: Edison Su
Cc: [email protected]
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 KVMStoragePoolManager.java based on what primary storage
type I happen to be acting upon.
On Mon, Dec 10, 2012 at 12:51 PM, Edison Su
<[email protected]<mailto:[email protected]>> wrote:
From: Marcus Sorensen [mailto:[email protected]<mailto:[email protected]>]
Sent: Monday, December 10, 2012 2:06 PM
To: Edison Su
Cc:
[email protected]<mailto:[email protected]>
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:
https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob;f=plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/StorageAdaptor.java;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.
