Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
On Thu, Apr 22, 2010 at 01:45:27PM -0500, Anthony Liguori wrote:
On 04/09/2010 09:27 AM, Daniel P. Berrange wrote:
>On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
>
>
>><domain type='kvm'>
>> <name>myguest</name>
>> ...
>> <debug>
>> <monitorpassthrough/>
>> <commandline>
>> <extra>qemu arguments</extra>
>> <alter option="optname">
>> <rename>newname</rename>
>> <match>REGEXP</match>
>> <modify>foo=on</modify>
>> <extra>-bar</extra>
>> </alter>
>> </commandline>
>> </debug>
>></domain>
>>
>The concept of command line& monitor is something that is QEMU specific
>and thus is not suitable for the primary XML schema. IMHO, this needs to be
>done as a separate schema, linked in via an XML namespace. For example
>
> <domain type='kvm'
> xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">
> <name>myguest</name>
> ...
> <qemu:commandline>
> <qemu:arg>-device</arg>
> <qemu:arg>lsi</arg>
> </qemu:commandline>
> </domain>
>
I think it's problematic to focus too much on command line arguments.
We are not introducing new command line arguments to qemu for the most
part that aren't usable in the config file.
Currently libvirt doesn't use any config file at all, so command line
is the only possible option. We're going to evaluate switching to the
config file at some point & so can easily add further XML options to
allow direct setting of config file entries at that point. There's no
problem supporting both command line & config file syntax in the XML.
The command line does have the immediate advantage that 99% of all
documentation about QEMU on the web today refers to command line args
so that's what people are most familiar with.
With respect to injecting QMP commands directly, I think the proposed
debug API is probably reasonable. We could build a libqemu that used
that API as a transport which means that one could use libqemu and
libvirt simultaneously which is certainly a key requirement of mine.
I think it's important that it's a dedicated monitor session though. It
shouldn't just be injecting commands within an existing QMP session IMHO.
I think the opposite actually. If libvirt had two open monitor connections,
one for normal use & one for injection, then its open to racey usage where
2 monitor commands may be issued concurrently & it is tricky to determine
just which will be processed first, with all the scope for unexpected
behaviour this entails. With a single monitor connection, libvirt's current
locking model for the monitor ensures that QMP monitor commands are reliably
serialized onto the wire, giving unambiguous behaviour.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|