Discussion: 312 - LVM VG is left when removing logical storage pool
Well, you can also test using virsh. Libvirt is not removing the vg and the pv when you delete a logical storage pool. The question is: is it better to fix libvirt, submiting a patch for they, or just remove the vg and pv on kimchi? -- Ramon Nunes Medeiros Software Engineer - Linux Technology Center Brazil IBM Systems & Technology Group Phone : +55 19 2132 7878 ramonn@br.ibm.com
On 01/28/2014 11:29 AM, Ramon Medeiros wrote:
Well,
you can also test using virsh. Libvirt is not removing the vg and the pv when you delete a logical storage pool.
The question is: is it better to fix libvirt, submiting a patch for they, or just remove the vg and pv on kimchi?
I don't think it is a libvirt problem. Deleting a storage pool should not affect the system as storage pool is just a concept. From kimchi perspective, we should allow the user create the logical storage pool with any name independent if it was created earlier or not What we need to do is investigating if there is a way to create a logical pool with name "my-logical-pool" and the vg with a unique key, like "my-logical-%(uuid)s" So we guarantee the logical pool name won't affect the vg name.
Hi Aline, i can't make the VG with the name you suggested: %(name)s-uuid, i tried to pass this in XML but libvirt will create in the old way, with the volume group using the same name of the logical storage pool. But, even if it was possible, how can this will fix this problem? The partition that was used to make the storage pool would be used by the vg, and won't be available to create a new storage pool. On 01/29/2014 12:39 PM, Aline Manera wrote:
On 01/28/2014 11:29 AM, Ramon Medeiros wrote:
Well,
you can also test using virsh. Libvirt is not removing the vg and the pv when you delete a logical storage pool.
The question is: is it better to fix libvirt, submiting a patch for they, or just remove the vg and pv on kimchi?
I don't think it is a libvirt problem. Deleting a storage pool should not affect the system as storage pool is just a concept.
From kimchi perspective, we should allow the user create the logical storage pool with any name independent if it was created earlier or not
What we need to do is investigating if there is a way to create a logical pool with name "my-logical-pool" and the vg with a unique key, like "my-logical-%(uuid)s" So we guarantee the logical pool name won't affect the vg name.
-- Ramon Nunes Medeiros Software Engineer - Linux Technology Center Brazil IBM Systems & Technology Group Phone : +55 19 2132 7878 ramonn@br.ibm.com
On 01/29/2014 04:46 PM, Ramon Medeiros wrote:
Hi Aline,
i can't make the VG with the name you suggested: %(name)s-uuid, i tried to pass this in XML but libvirt will create in the old way, with the volume group using the same name of the logical storage pool.
hmm ok =/
But, even if it was possible, how can this will fix this problem? The partition that was used to make the storage pool would be used by the vg, and won't be available to create a new storage pool.
But when creating a pool with the same name created before the new vg will have a new name. Example: I create a *pool* named "my-logical-pool". It will create a vg named "my-logical-pool" When deleting the pool "my-logical-pool" the vg will keep there. So when I try to create a new pool (with other free disks) named "my-logical-pool" it will try to create a vg with this name which already exists - then the error. So if we unlink the pool name from the vg name we can avoid this kind of errors. But as you verified it is not possible we need to find other solution. 1) delete the vg while deleting the pool (?) I don't like this approach as pool is a concept and should not impact the system 2) Warn the user about the existing vg and ask if he want to use this one 3) Verify vg exists and ask user to choose other pool name All those are possibilities. We need to figure out which one fits better the user needs.
On 01/29/2014 12:39 PM, Aline Manera wrote:
On 01/28/2014 11:29 AM, Ramon Medeiros wrote:
Well,
you can also test using virsh. Libvirt is not removing the vg and the pv when you delete a logical storage pool.
The question is: is it better to fix libvirt, submiting a patch for they, or just remove the vg and pv on kimchi?
I don't think it is a libvirt problem. Deleting a storage pool should not affect the system as storage pool is just a concept.
From kimchi perspective, we should allow the user create the logical storage pool with any name independent if it was created earlier or not
What we need to do is investigating if there is a way to create a logical pool with name "my-logical-pool" and the vg with a unique key, like "my-logical-%(uuid)s" So we guarantee the logical pool name won't affect the vg name.
-- Ramon Nunes Medeiros Software Engineer - Linux Technology Center Brazil IBM Systems & Technology Group Phone : +55 19 2132 7878 ramonn@br.ibm.com
participants (2)
-
Aline Manera -
Ramon Medeiros