[libvirt] [RFC] Add flag for virsh undefine to remove/wipe the disk devices
Osier Yang
jyang at redhat.com
Thu Mar 31 07:57:35 UTC 2011
于 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 :)
>
More information about the libvir-list
mailing list