Re: [libvirt] [RFC] Add flag for virsh undefine to remove/wipe the disk devices
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)