[Kimchi-devel] RFC: "Add disk to existing logical storage pool"

Daniel H Barboza danielhb at linux.vnet.ibm.com
Tue Feb 4 12:42:04 UTC 2014


Update:

I've spent some time trying to find out the behavior of vgextend and how 
to extend an existing LVM pool. After a while I've found this link, from 
the "libvirt-users" mailing list:

https://www.redhat.com/archives/libvirt-users/2013-September/msg00136.html

The interesting part is this:

"

On 21/09/13 02:15, McEvoy, James wrote:

    I looked around but could not find any info on how to expand a libvirt managed LVM storage pool.  I do not see any virsh command to do it
    but I was successful using the vgexpand command to add some more storage once I destroyed the pools and then restarted it.
    I'd like to verify that this is the proper way to grow the storage in a libvirt LVM storage pool.


It's not the proper way in principle, but since libvirt doesn't 
supportto extendthe volume groups for a logical pool yet, it's the only 
way now. Onehint though,you can try to refresh the pool by command 
"virsh pool-refresh" afterthe volume

group of the pool is extended. I.e, don't have to restart the pool."


In short, the recommended way to do it is using vgextend + pool-refresh. 
I've tried it and it works. But (there's always a "but") this process 
does not update the pool XML. And I'm not sure if it's supposed to.

I can submit a v1 patch with this implementation, but it would be 
awesome if a more experienced libvirt user/programmer could shed some 
light in this matter. I'm willing to send an email to libvirt-users ML 
if we do not have such expert here.

Thanks!

On 02/03/2014 10:00 AM, Aline Manera wrote:
> On 01/31/2014 05:13 PM, Daniel H Barboza wrote:
>>
>> On 01/31/2014 04:25 PM, Aline Manera wrote:
>>>
>>> Hi Daniel,
>>>
>>> Did you try to edit the pool xml and add a new device for it? 
>>> Instead of doing it manually though vgextend command
>>>
>>> For example:
>>>
>>> virsh pool-destroy lvm-pool
>>>
>>> virsh pool-edit lvm-pool
>>> (add a new device for it)
>>>
>>> virsh pool-start lvm-pool
>>>
>>> I don't know if it is possible but we give it a try
>> Haven't tried it. Definitely worth a try.
>>
>> Another question: maybe I could add some remove disk from LVM feature 
>> as well? If we support adding we should support removing... right? 
>> There is this caveat where removing a disk from a LVM can "corrupt" 
>> the data of the remaining pool. One solution to that would be to 
>> destroy/restart the LVM pool if a disk removal happens.
>>
>> HHmmmm perhaps the removal of disks would be very similar to simply 
>> delete the pool and re-create it with fewer disks, so no point in 
>> trying to implement a new way to do the same thing .... thoughts?
>>
>
> Agree. We should not care about removal disks from a logical storage 
> pool.
> The best way to do it (from user view) is deleting the pool and 
> creating a new one with few disks.
>
>>>
>>> Regards,
>>> Aline Manera
>>>
>>> On 01/31/2014 11:42 AM, Daniel H Barboza wrote:
>>>> Hello!
>>>>
>>>> I am almost delivering a first version of this feature but now I am 
>>>> having doubts in how it might work or not.
>>>>
>>>> My implementation would use vgextend and add a disk to an existing 
>>>> LVM pool. The question is that, in this process, all existing data 
>>>> in the added partition will be deleted. Is this ok? We can warn the 
>>>> user about it, of course. But I am not sure if this is the intended 
>>>> design.
>>>>
>>>> I've spoken with Aline a while ago and she agreed that the 
>>>> implementation would function similar to what we have today when 
>>>> creating a new LVM pool. We simply "do not care" about the 
>>>> potential data loss when adding the disk to an existing pool.
>>>>
>>>> Any thoughts?
>>>>
>>>>
>>>> thanks!
>>>>
>>>> _______________________________________________
>>>> Kimchi-devel mailing list
>>>> Kimchi-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140204/13547ad2/attachment.html>


More information about the Kimchi-devel mailing list