-----Original Message-----
From: rhevm-api-bounces(a)lists.fedorahosted.org [mailto:rhevm-api-
bounces(a)lists.fedorahosted.org] On Behalf Of Mark McLoughlin
Sent: Wednesday, April 21, 2010 20:11 PM
To: rhevm-api
Subject: [rhevm-api] Storage domains
Hey,
I started taking a look at how we should model storage domains
First off some definitions:
- Data center - toplevel container of host clusters, storage domains
and logical networks; a data center can only use one
type of storage (e.g. NFS or iSCSI, not both)
[IH] this may
change (more than one type of storage)
- Host cluster - a collection of hosts forming a migration domain
(i.e. RHEV-M should be able to migrate a VM to any
host within a given cluster). That implies that all
hosts within a cluster have the same type of CPU and
access to the same storage
- Storage Domain - a pool from which disk images can be allocated for
VMs and templates; e.g. an NFS storage domain is
an NFS mounted directory where RHEV-M can create
disk image as files.
Storage domains can be 'data', 'iso' or
'export'
domains depending on whether they contain disk
images, isos or exported VM images
Storage domains can be attached to and detached
from a data center - i.e. there exists an
"unattached" state where it is not associated with
a data center
Here's what the XML for a storage domain might look like:
<storage_domain>
<id>76d8a12c-8b15-45f9-afc7-510f2377da74</id>
<name>images_0</name>
<link rel="self" href="/storage_domains/76d8a12c-8b15-45f9-
afc7-510f2377da74"/>
<type>data</type>
<link rel="datacenter" href="/datacenters/24aa455a-4cde-4201-
a36b-cd9c4358e902"/>
<storage type="nfs">
<host name="172.31.0.6"/>
<directory path="/exports/RHEV/images/0"/>
</storage>
<available>128849018880</available>
...
</storage_domain>
Pretty straightforward, but there are details worth thinking about:
- I'm using <link/> here, but I think the <object
href="..."/>
equal merit - we've got to decide on this soon :-)
<storage_domain href="...">
...
<datacenter href="..."/>
...
</storage_domain>
- Should 'type' be an attribute?
<storage_domain type='data'>
...
</storage_domain>
- The <host> and <directory> elements I copied from libvirt because I
didn't see any reason not to:
http://libvirt.org/formatstorage.html
Okay, that's all fairly boring so far, but let's look at what
parameters
are required to create a storage domain in powershell:
Add-StorageDomain -Storage <String> -HostId <Int32>
-DomainType <StorageDomainType>
-StorageType <StorageType> -Name <String>
That's all fine, except HostId. Notice there is no reference to a host
in the XML modelling above!
That's because a storage domain isn't directly associated with a host,
but you do need a host in order to create it (e.g. some host on which
we'll mount the NFS directory and create the metadata for the domain).
Options I see:
1) Require a 'host' reference in the document POSTed to the
storage_domains collection, but never include a 'host' reference
in a storage domain document returned by the server
POST /storage_domains HTTP/1.1
Content-Type: application/xml
Content-Length: {length}
<storage_domain type='data'>
<name>images_0</name>
<host href='/hosts/288478f3-f4c9-4589-b4f5-d6522501762e'/>
<storage type='nfs'>
<host name='172.31.0.6'/>
<directory path='/exports/RHEVX/images/0'/>
</storage>
</storage_domain>
HTTP/1.1 201 Created
Location: http://{host}/storage_domains/76d8a12c-8b15-45f9-afc7-
510f2377da74
Content-Type: application/xml
Content-Length: <length>
<storage_domain type='data' href='/storage_domains/76d8a12c-8b15-
45f9-afc7-510f2377da74'>
<id>76d8a12c-8b15-45f9-afc7-510f2377da74</id>
<name>images_0</name>
<storage type='nfs'>
<host name='172.31.0.6'/>
<directory path='/exports/RHEVX/images/0'/>
</storage>
<available>128849018880</available>
</storage_domain>
Seems pretty strange to me
2) Use a different document format at creation time. Same as above,
except the root element would be e.g.
<storage_domain_add_request/>
Eoghan touches on that option here:
https://www.redhat.com/archives/rest-practices/2010-
April/msg00041.html
I'm not loving that either, we'll end up with 2 or 3 times the
number of document formats
3) Don't require a host to be specified and randomly choose a host to
use when creating a storage domain
[IH] this is not an option. You need to
select a host that can actually
access said storage.
4) Require a data center to be specified at creation time and
use that to choose a host from one of the clusters in the data
center. We could remember that data center and allow no data
center to be specified when invoking 'attach' later.
[IH] this
requires that setting the storage domain all hosts will already
have access to it in the cluster. Sounds a bit limiting. One could also
later attach it to another storage domain.
Btw - a storage domain can be attached to multiple data centers, and may
have a different status in each of them.
5) Same as (4), except we automatically attach the storage domain to
the cluster as part of the creation. We would still have 'detach'
and 'attach' actions, though.
[IH] this makes creation of a storage
domain an action that has to be
synchronized on all hosts in a data center.
I'm liking the latter option. Anyone else have thoughts? Anyone else
read this far? :-)
[IH] I'm not sure I see the issue with passing a parameter
of the host you
want to use to the storage domain creation request, even if it is not part
of the response?