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(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>