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

Daniel Veillard veillard at redhat.com
Wed Mar 30 13:50:19 UTC 2011


On Wed, Mar 30, 2011 at 09:39:14PM +0800, 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:
> 
> 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).
> 
>    And for the disk path which doesn't belong to any storage pool,
>    simply remove it by "unlink()"?

  Won't work for connection to remote hosts.

> 2) Which type of devices can not be removed/wiped.
> 
>    * Can't delete/wipe ISCSI/SCSI vol.
>    * Vol doesn't exists (which will throw an warning when do
>      virStorageVolLookupByPath).
>    * 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)
>    * 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.

  I would rather make this a flag of virDomainUndefine(), except
there is no flag argument for it :(

  I think if we want this to work well tis should be based on
API operations only,

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/




More information about the libvir-list mailing list