ä 2011å03æ30æ 23:23, 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"?
And also a new API to get the disks of domain? so that we don't
need to parse the XML directly. :-)
I think if we want this to work well tis should be based on
API operations only,
Daniel
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list