[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [Qemu-devel] Re: Libvirt debug API



On Fri, Apr 23, 2010 at 08:40:49AM -0500, Anthony Liguori wrote:
> On 04/23/2010 05:28 AM, Daniel P. Berrange wrote:
> >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.
> 
> The config file is really just a structured command line argument so the 
> two are really equivalent.
> 
> From an XML perspective, the advantage of using the config file format 
> is that it's very well structured whereas the command line arguments 
> aren't.  It's the difference between:
> 
> <qemu:commandline>
> <arg>-drive</arg>
> <arg>file=foo.img,if=virtio,cache=off</arg>
> </qemu:commandline>
> 
> And:
> 
> <qemu:drive>
> <file>foo.img</file>
> <if>virtio</if>
> <cache>off</cache>
> </qemu:drive>
> 
> The later being much more friendly for things like XPath and XQuery.
> 
> >  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.
> 
> I don't necessary think there's a super compelling reason for you to 
> switch to pure config.  Some things you'll have to do via -device and 
> -set but it's still reasonable to keep using the command line.  A key 
> requirement of the config file effort was that everything that can be 
> done via config file be doable via command line.

The main reason  we're interested in the config is that it uses a better
structured format, so we don't have such hairy escaping problems to deal
with. Also, the command line is getting outrageously long these days
with -device syntax.

> >>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.
> 
> Can you give an explicit example?  The nature of this debug extension is 
> such that I don't think 1 monitor really helps this problem...

Say libvirt is running a 'offline core dump' operation. This consists of
us invoking

   stop
   migrate exec:cat > foo.dump
   cont

I don't want other debug commands accidentally being issued in between
these steps. These 3 commands are in essence considered transactional
block. Internally our locking model ensures that no other APIs can be
invoked in this monitor connection during this sequence. Thus if someone
uses the libvirt debug API to issue a monitor command, thus command will
be blocked until the last 'cont' command is issued here. This provides us
a known command ordering in the logs. 

> >  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.
> 
> Except that libvirt doesn't know what the side effects of the debug 
> commands are so it's intrinsically ambiguous :-)

This is a different ambiguity, about the semantic results of the commands,
where as I'm refering to the execution order. If I look at a libvirt log
file and see a set of JSON commands logged, I want to know that this ordering
from the logs, was indeed the same as order in which qemu processed them. If
you have two separate monitor connection you can't be sure of the order of 
execution. It is key for our bug troubleshooting that given a libvirt log 
file, we can replay the JSON commands again and get the same results. Two
monitor connections is just increasing complexity of code without any 
tangible benefit.

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]