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

[Osier Yang]

于 2011年03月30日 21:50, Daniel Veillard 写道:
> 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.

Hmm, yes, :-)

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

Yes, actually I also prefer to add new flag to API, but not in
virsh instead, however, adding new flag argument is not workable,
how about introduce a new API, something like "virDomainUndefineFlag"?

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