[libvirt] [PATCH] disk: Fixup error handling path for devmapper when part_separator='yes'
John Ferlan
jferlan at redhat.com
Sat Jan 7 18:47:56 UTC 2017
ping**3
Thanks
John
On 12/15/2016 05:35 PM, John Ferlan wrote:
> ping?
>
> Thanks -
>
> John
>
> On 12/03/2016 09:06 AM, John Ferlan wrote:
>>
>> ping?
>>
>> Tks -
>>
>> John
>>
>> On 11/17/2016 09:55 AM, John Ferlan wrote:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1346566
>>>
>>> If libvirt_parthelper is erroneously told to append the partition
>>> separator 'p' onto the generated output for a disk pool using device
>>> mapper that has 'user_friendly_names' set to true, then the error
>>> recovery path will fail to find volume resulting in the pool being
>>> in an unusable state.
>>>
>>> So, augment the documentation to provide the better hint that the
>>> part_separator='yes' should be set when user_friendly_names are not
>>> being used. Additionally, once we're in the error path where the
>>> returned name doesn't match the expected partition name try to see
>>> if the reason is because the 'p' was erroneosly added. If so alter
>>> the about to be removed vol->target.path so that the DiskDeleteVol
>>> code can find the partition that was created and remove it.
>>>
>>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>>> ---
>>> docs/formatstorage.html.in | 5 ++++-
>>> src/storage/storage_backend_disk.c | 23 +++++++++++++++++++++++
>>> 2 files changed, 27 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in
>>> index ed1f0d1..7690114 100644
>>> --- a/docs/formatstorage.html.in
>>> +++ b/docs/formatstorage.html.in
>>> @@ -138,7 +138,10 @@
>>> causes libvirt to attempt to generate and find target volume path's
>>> using a "p" separator. The default algorithm used by device mapper
>>> is to add the "p" separator only when the source device path ends
>>> - with a number.
>>> + with a number; however, it's possible to configure the devmapper
>>> + device to not use 'user_friendly_names' thus creating partitions
>>> + with the "p" separator even when the device source path does not
>>> + end with a number.
>>> <span class="since">Since 1.3.1</span></p></dd>
>>> <dt><code>dir</code></dt>
>>> <dd>Provides the source for pools backed by directories (pool
>>> diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c
>>> index 666ad03..07a04f1 100644
>>> --- a/src/storage/storage_backend_disk.c
>>> +++ b/src/storage/storage_backend_disk.c
>>> @@ -95,6 +95,29 @@ virStorageBackendDiskMakeDataVol(virStoragePoolObjPtr pool,
>>> virReportError(VIR_ERR_INVALID_ARG,
>>> _("invalid partition name '%s', expected '%s'"),
>>> vol->name, partname);
>>> +
>>> + /* Let's see if we by chance parthelper created a name that won't be
>>> + * found later when we try to delete. We tell parthelper to add a 'p'
>>> + * to the output via the part_separator flag, but if devmapper has
>>> + * user_friendly_names set, the creation won't happen that way, thus
>>> + * our deletion will fail because the name we generated is wrong.
>>> + * Check for our conditions and see if the generated name is the
>>> + * same as StablePath returns and has the 'p' in it */
>>> + if (pool->def->source.devices[0].part_separator ==
>>> + VIR_TRISTATE_BOOL_YES &&
>>> + !virIsDevMapperDevice(vol->target.path) &&
>>> + STREQ(groups[0], vol->target.path) &&
>>> + (tmp = strrchr(groups[0], 'p'))) {
>>> +
>>> + /* If we remove the 'p' from groups[0] and the resulting
>>> + * device is a devmapper device, then we know parthelper
>>> + * was told to create the wrong name based on the results.
>>> + * So just remove the 'p' from the vol->target.path too. */
>>> + memmove(tmp, tmp + 1, strlen(tmp));
>>> + if (virIsDevMapperDevice(groups[0]) &&
>>> + (tmp = strrchr(vol->target.path, 'p')))
>>> + memmove(tmp, tmp + 1, strlen(tmp));
>>> + }
>>> return -1;
>>> }
>>>
>>>
>>
>> --
>> libvir-list mailing list
>> libvir-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
>>
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
More information about the libvir-list
mailing list