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

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

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 >

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 >>> >> >