Re: [libvirt] [virt-tools-list] [RFC] virt-disk : a command line tool for modify domain XML's disk of inactive domains.
On 02/21/2011 07:20 PM, Eric Blake wrote:
On 02/21/2011 05:04 PM, KAMEZAWA Hiroyuki wrote:
> On Mon, 21 Feb 2011 08:17:30 -0700
> Eric Blake <eblake(a)redhat.com> wrote:
>
>> On 02/21/2011 01:23 AM, KAMEZAWA Hiroyuki wrote:
>>> Hi, now, with qemu, virsh attach-disk doesn't work with inactive disks
and
>>> we need to edit XML with virsh edit.
>>> IIUC, libvirt and virsh is designed as it is.
>>
>> Actually, libvirt should be patched to learn how to modify xml of
>> inactive disks for qemu (it already can do it for xen, so the API is
>> already present, it's just that no one has wired up that API for qemu).
>>
>
> Before starging this, I thought of that. I did this in python by 3 reasons.
>
> 1. When we asked "Is it a spec that we cannot modify inactive domain ?" to
> a Redhat guy, he answered "it's a spec".
> Do you, maintainers, have some concensus about this ?
'virsh attach-disk --persistent' is supposed to be able to modify an
inactive domain. If it doesn't do so for qemu, then that's because no
one has yet implemented it correctly, which means libvirt has a bug that
needs to be patched. For example, see:
https://bugzilla.redhat.com/show_bug.cgi?id=669549
about 'virsh setmem --config' not working for qemu.
Personally I don't think these flags should be implemented anywhere besides
the xen driver where they are needed for back compat. Persistently adding
devices is something that can be done by an API user in a few dozen lines of
code, and it will work for all drivers.
If we want virsh to expose this capability, we should just add a generic
implementation there.
>
> 2. virsh attach-disk doesn't seem to support misc. options. It doesn't have
> - boot_order
> - shareable
> - serial
> - io
> - error_policy
> etc...
If there's something that the libvirt API supports, but which virsh does
not support, then that's a bug in virsh. Please let us know about these
usability deficiencies in virsh, since that is the right place to be
patching it for use by all other shell-based tools, rather than
reinventing a new tool by every user.
There are 2 distinct pieces of the libvirt API: API calls and XML building.
Both are very large topics in their own right, and I think trying to have a
single tool that exposes every nuance of both would be cumbersome. Right now
virsh is mostly just an API call wrapper, which is what it should stay IMO.
XML building/editing is also closely tied with validation, and higher level
operations like creating storage or fixing storage permissions, none of which
should live in virsh IMO.
Thanks,
Cole