[libvirt] [PATCH 07/10] storage: Implement ephemeral storage APIs for local disk volumes
Peter Krempa
pkrempa at redhat.com
Fri Jan 10 16:38:24 UTC 2014
On 01/10/14 00:39, Eric Blake wrote:
> On 01/09/2014 09:15 AM, Peter Krempa wrote:
>> This patch implements the APIs for getting temporary storage pools for
>> the local filesystem driver using storage_backend_fs.
>> ---
>> src/check-aclrules.pl | 3 +
>> src/storage/storage_driver.c | 253 +++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 256 insertions(+)
>>
>
>> + /* generate a unique name */
>> + do {
>> + if (pool) {
>> + virStoragePoolObjUnlock(pool);
>> + pool = NULL;
>> + }
>> +
>> + storageEphemeralGenerateUniquePoolID(def);
>> +
>> + if ((pool = virStoragePoolObjFindByUUID(&driver->pools, def->uuid)))
>> + continue;
>> +
>> + pool = virStoragePoolObjFindByName(&driver->pools, def->name);
>> + } while (pool);
>
> This avoids a collision with any existing pools, but what if we pick a
> name that a later public API also picks - will the public API be
> rejected, or will our internal pool be automatically upgraded to be
> tagged as an existing pool? (Not that generated UUIDs are likely to
> collide, but you never know...)
The new user defined pool will be rejected in that case. I think that
the chance of collision is minimal (but still existing). We could also
dedicate a forbidden prefix or look for characters forbidden in the RNG
schema and use those as a prefix to avoid "legitimate" collisions.
>
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140110/b209c59c/attachment-0001.sig>
More information about the libvir-list
mailing list