[libvirt] [PATCH] storage: Do not use comma as seperator for lvs output

Osier Yang jyang at redhat.com
Thu Sep 22 09:08:13 UTC 2011


于 2011年09月22日 16:41, Eli 写道:
> hi Osier:
> 于 2011年09月22日 15:08, Osier Yang 写道:
>> 于 2011年09月22日 14:31, Eli 写道:
>>> hi Osier :
>>> 于 2011年09月21日 17:07, Osier Yang 写道:
>>>> * src/storage/storage_backend_logical.c:
>>>>
>>>> If a logical vol is created with multiple stripes. (e.g. --stripes 3),
>>>> the "device" field of lvs output will have multiple fileds which are
>>>> seperated by comma. It means the RE we write in the codes will not
>>>> work well anymore. E.g. (lvs output for a stripped vol, uses "#" as
>>>> seperator here):
>>>>
>>>> test_stripes##fSLSZH-zAS2-yAIb-n4mV-Al9u-HA3V-oo9K1B#\
>>>> /dev/sdc1(10240),/dev/sdd1(0)#42949672960#4194304
>>>>
>>>> The RE we uses:
>>>>
>>>>      const char *regexes[] = {
>>>>          
>>>> "^\\s*(\\S+),(\\S*),(\\S+),(\\S+)\\((\\S+)\\),(\\S+),([0-9]+),?\\s*$"
>>>>      };
>>>>
>>>> This patch changes the seperator into "#" to fix the problem.
>>>>
>>>> Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=727474
>>>> ---
>>>>   src/storage/storage_backend_logical.c |    7 ++++---
>>>>   1 files changed, 4 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/src/storage/storage_backend_logical.c 
>>>> b/src/storage/storage_backend_logical.c
>>>> index 4f42047..45f77ad 100644
>>>> --- a/src/storage/storage_backend_logical.c
>>>> +++ b/src/storage/storage_backend_logical.c
>>>> @@ -187,19 +187,20 @@ 
>>>> virStorageBackendLogicalFindLVs(virStoragePoolObjPtr pool,
>>>>        *
>>>>        * NB can be multiple rows per volume if they have many extents
>>>>        *
>>>> -     * NB lvs from some distros (e.g. SLES10 SP2) outputs trailing 
>>>> "," on each line
>>>> +     * NB lvs from some distros (e.g. SLES10 SP2) outputs trailing
>>>> +     * @separator on each line
>>>>        *
>>>>        * NB Encrypted logical volumes can print ':' in their name, 
>>>> so it is
>>>>        *    not a suitable separator (rhbz 470693).
>>>>        */
>>>>       const char *regexes[] = {
>>>> -        
>>>> "^\\s*(\\S+),(\\S*),(\\S+),(\\S+)\\((\\S+)\\),(\\S+),([0-9]+),?\\s*$"
>>>> +        
>>>> "^\\s*(\\S+)#(\\S*)#(\\S+)#(\\S+)\\((\\S+)\\)#(\\S+)#([0-9]+)#?\\s*$"
>>>>       };
>>>>       int vars[] = {
>>>>           7
>>>>       };
>>>>       const char *prog[] = {
>>>> -        LVS, "--separator", ",", "--noheadings", "--units", "b",
>>>> +        LVS, "--separator", "#", "--noheadings", "--units", "b",
>>>>           "--unbuffered", "--nosuffix", "--options",
>>>>           "lv_name,origin,uuid,devices,seg_size,vg_extent_size",
>>>>           pool->def->source.name, NULL
>>>
>>> I reproduced the bug :
>>>
>>> [root at localhost bin]# ./virsh -d 5 pool-create-as vg_ssd logical 
>>> --target /dev/vg_ssd
>>> error: Failed to create pool vg_ssd
>>> error: cannot open volume '/dev/vg_ssd/test_stripes,': No such file 
>>> or directory
>>>
>>> and then I tested this patch , it seems work well.
>>>
>>> [root at localhost bin]# ./virsh -d 5 pool-create-as vg_ssd logical 
>>> --target /dev/vg_ssd
>>> Pool vg_ssd created
>>>
>>> [root at localhost bin]# ./virsh pool-info vg_ssd
>>> Name: vg_ssd
>>> UUID: c45cc84e-7879-cc15-ee78-2d2dda6b531d
>>> State: running
>>> Persistent: no
>>> Autostart: no
>>> Capacity: 200.00 MB
>>> Allocation: 152.00 MB
>>> Available: 48.00 MB
>>>
>>
>> Thanks for the testing, Eli,
>>
>> Could you also check what's the vol XML?  I want to confirm if the
>> "<extents>" in "<source><device></device></source>"displays well,
>> though it looks to me there is no "<path>" element defined for 
>> "<extents>"
>> in the storage vol schema yet.
>>
> 1. my vol XML is like this:
>
>   virsh # vol-dumpxml test_stripes --pool vg_ssd
> <volume>
> <name>test_stripes</name>
> <key>1pc6Gf-1hn2-WGnw-ASKt-uX6w-xUed-qERq50</key>
> *<source>
> <device path='/dev/sdb(0),/dev/sdc'>
> *

This is expected, and is what's Daniel Berrange worried about.

> *<extent start='0' end='159383552'/>
> </device>
> </source>*

Thanks
Osier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110922/e5df224a/attachment-0001.htm>


More information about the libvir-list mailing list