5:23 a.m.
Hi All
I am working on integrating GlusterFS with OpenStack so that VM volumes can
be placed on shared GlusterFS volumes. I would highly appreciate if you
please help me find the answers to some questions:
1. Whats the difference between a storage driver and a storage backend driver?
2. Why does virDomainAttachDevice code path call the corresponding
domainAttach function in the hypervisor driver and not the volume or pool
creation method if a disk is being attached? Does it assume that the volume
has already been created before this call?
3. Which part of libvirtd source handles receiving messages from the
libvirt client?
Thanks
-Shehjar
3:58 p.m.
On 06/30/2011 04:23 AM, Shehjar Tikoo wrote:
Hi All
I am working on integrating GlusterFS with OpenStack so that VM volumes
can be placed on shared GlusterFS volumes. I would highly appreciate if
you please help me find the answers to some questions:
1. Whats the difference between a storage driver and a storage backend
driver?
A storage driver implements the callbacks used by the public API, as
called from src/libvirt.c. Most hypervisors can use the generic storage
driver in src/storage/, but some use their own (such as
src/esx/esx_storage_driver.c).
A storage backend driver implements additional callbacks, so that the
generic storage driver can target several types of storage devices. It
sounds like your work on GlusterFS would be a storage callback driver,
and that all hypervisors that defer to the generic storage driver (such
as qemu and lxc) will then automatically know how to do operations on
images stored in GlusterFS.
2. Why does virDomainAttachDevice code path call the corresponding
domainAttach function in the hypervisor driver and not the volume or
pool creation method if a disk is being attached? Does it assume that
the volume has already been created before this call?
The virDomainAttachDevice API is for hot-plugging an existing disk into
a running VM. It is not about disk creation (although if that proves
useful and common enough, we could possibly introduce some flags to both
allocate and attach storage volumes via a single API).
3. Which part of libvirtd source handles receiving messages from the
libvirt client?
daemon/remote.c receives all RPC messages from the libvirt client.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
3:27 a.m.
Eric Blake wrote:
On 06/30/2011 04:23 AM, Shehjar Tikoo wrote:
> Hi All
>
> I am working on integrating GlusterFS with OpenStack so that VM volumes
> can be placed on shared GlusterFS volumes. I would highly appreciate if
> you please help me find the answers to some questions:
>
> 1. Whats the difference between a storage driver and a storage backend
> driver?
A storage driver implements the callbacks used by the public API, as
called from src/libvirt.c. Most hypervisors can use the generic storage
driver in src/storage/, but some use their own (such as
src/esx/esx_storage_driver.c).
A storage backend driver implements additional callbacks, so that the
generic storage driver can target several types of storage devices. It
sounds like your work on GlusterFS would be a storage callback driver,
and that all hypervisors that defer to the generic storage driver (such
as qemu and lxc) will then automatically know how to do operations on
images stored in GlusterFS.
What I find is that virStorageBackendFileSystemMount already implements
support for GlusterFS and I know that the GlusterFS support currently is
for the volume which is going to store VM images/running state and not
EBS style attachable volumes. This seems to suggest that a different
code path is where the change will be needed to support EBS-style
volumes over GlusterFS. Do I understand this right?
Thanks
-Shehjar
3:27 a.m.
Eric Blake wrote:
On 06/30/2011 04:23 AM, Shehjar Tikoo wrote:
> Hi All
>
> I am working on integrating GlusterFS with OpenStack so that VM volumes
> can be placed on shared GlusterFS volumes. I would highly appreciate if
> you please help me find the answers to some questions:
>
> 1. Whats the difference between a storage driver and a storage backend
> driver?
A storage driver implements the callbacks used by the public API, as
called from src/libvirt.c. Most hypervisors can use the generic storage
driver in src/storage/, but some use their own (such as
src/esx/esx_storage_driver.c).
A storage backend driver implements additional callbacks, so that the
generic storage driver can target several types of storage devices. It
sounds like your work on GlusterFS would be a storage callback driver,
and that all hypervisors that defer to the generic storage driver (such
as qemu and lxc) will then automatically know how to do operations on
images stored in GlusterFS.
What I find is that virStorageBackendFileSystemMount already implements
support for GlusterFS and I know that the GlusterFS support currently is
for the volume which is going to store VM images/running state and not
EBS style attachable volumes. This seems to suggest that a different
code path is where the change will be needed to support EBS-style
volumes over GlusterFS. Do I understand this right?
Thanks
-Shehjar
4918
days inactive
4930
days old
3 comments
2 participants
participants (2)
-
Eric Blake -
Shehjar Tikoo