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

[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; 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.

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

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110330/8ef7a33d/attachment-0001.sig>