Re: [libvirt] [RFC] Add flag for virsh undefine to remove/wipe the disk devices

On 03/30/2011 07:39 AM, Osier Yang wrote: > Hi, All > > I'm thinking to introduce a new flag (something like --remove-disks, > --wipe-disks) for "virsh undefine", so that the user can choose > whether to remove/wipe the disk devices or not, have seen this > requirement in many places, @libvirt-users, public #virt, and also > we have a bug of this function. So, IMHO this is a reasonable > requirement, following is the rough thoughts: I'm debating whether delete and wipe as two separate options make sense, or whether we only need one option. I guess for file-based volumes, there is a difference between leaving a wiped file behind and deleting the file altogether;

option. > > 1) General idea. > As we don't have a API which can get all the disk devices of a > domain, perhaps need to write functions to parse domain xml to > extract the disks' path (this is annoyed, but seems don't other > way), and then lookup them by storage volume API > (virStorageVolLookupByPath), and then can remove or wipe > the volume by (virStorageVolDelete/virStorageVolWipe). virt-manager has a gui option for deleting disks when deleting a domain; it achieves this by making multiple underlying API calls. You may want to use that implementation an example for a starting point. But it also has the advantage of listing all disks associated with the VM, and allowing fine-grain control over which volumes to keep or delete, whereas with virsh, it seems like a new --wipe-disks option would be all or none.

At any rate, I think that this is all at the virsh level, and doesn't need any new API additions in include/libvirt/libvirt.h.in. > > And for the disk path which doesn't belong to any storage pool, > simply remove it by "unlink()"? No, better would be to error out for any detected disk that cannot be resolved to a volume in a storage pool. > > 2) Which type of devices can not be removed/wiped. > > * Can't delete/wipe ISCSI/SCSI vol. Can't delete, but can wipe. > * Vol doesn't exists (which will throw an warning when do > virStorageVolLookupByPath). Can we tell the difference between a volume where the backing storage is located within an existing storage pool but the volume has already been deleted prior to deleting the guest XML, and the case of a guest XML that references a disk that does not belong to a storage pool? In the former case, requesting delete or wipe > * Have no write permission on the parent directory of the > disk path. > * Can't delete/wipe the disk device which is passthrough'ed > from host, (e.g. /dev/sr0 as a CDROM device for guest) /dev/sr0 would typically be a read-only volume. But I don't see why you can't wipe a read-write device passed through from the host (such as /dev/sda2). > * The storage pool which the disk device belongs to as a vol > is marked as "share" > * The storage pool which the disk device belongs as a vol is > readonly > * can't delete disk device of network type. > * Any others? > > For these situations, we need to do checking and throw > straightforward warnings to tell user why it can't be > removed/wiped. > > Any idea is welcomed. Thanks. Certainly post-0.9.0, whatever we come up with :)