于 2011年03月31日 01:11, Eric Blake 写道: > 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; yes, for fs pool based volumes, they are different. So I guess some user will require both of them. but for most other volume types, wiping is the only > 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. Yes, it has dialog box which can ask user to choose. But for virsh, don't think ask user interactively is a good idea. :-) > > 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 :) > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list