[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