[Qemu-devel] KVM call minutes for Oct 19

[Qemu-devel] KVM call minutes for Oct 19

[Chris Wright]

0.13.X -stable
- Anthony will send note to qemu-devel on this
- move 0.13.X -stable to a separate tree
- driven independently of main qemu tree
- challenge is always in the porting and testing of backported fixes
- looking for volunteers

0.14
- would like to do this before end of the year
- 0.13 forked off a while back (~July), 
- 0.14 features
  - QMP stabilized
    - 0.13.0 -> 0.14 QMP
    - hard attempt not to break compatibility
    - new commands, rework, async, human monitor passthrough
    - goal getting to libvirt not needing human monitor at all
    - QMP KVM autotest test suite submitted
- in-kernel apic, tpr patching still outstanding
- QED coroutine concurrency

Live snapshots
- merge snapshot?
  - already supported, question about mgmt of snapshot chain
- integrate with fsfreeze (and windows alternative)

Guest Agent
- have one coming RSN (poke Anthony for details)
- works over legacy or virtio serial
- simple RPC mechanism between host/guest
- allows host initiated reboot, for example
- can be place to do host driven snahpshot too
- Matahari?
  - can deal w/ block/net/UUID/cluster/etc
  - too heavyweight?
  - be sure to coordinate

threadlets and concurrency model (for virtfs)
- prior discussions
  - 1st model: http://www.mail-archive.com/qemu-devel@nongnu.org/msg43838.html
  - 2nd model: http://www.mail-archive.com/qemu-devel@nongnu.org/msg43921.html
  - threadlets: http://www.mail-archive.com/qemu-devel@nongnu.org/msg43842.html
- please review and continue discussion on the list
- concurrency model questions
  - async state machine is easiest to merge right now
  - future work could push it to cooperative coroutines

usb-ccid (aka external device modules such as vtpm)
- isolating device specific interface from qemu device internals is hard
- usb-ccid description...(go read the patches) 
- technical complexity with external emulation
  - version skew
  - live migration
  - same complextiy as full plug-in

Re: [Qemu-devel] KVM call minutes for Oct 19

[Alexander Graf]

On 19.10.2010, at 17:14, Chris Wright wrote:

> 0.13.X -stable
> - Anthony will send note to qemu-devel on this
> - move 0.13.X -stable to a separate tree
> - driven independently of main qemu tree
> - challenge is always in the porting and testing of backported fixes
> - looking for volunteers
> 
> 0.14
> - would like to do this before end of the year
> - 0.13 forked off a while back (~July), 
> - 0.14 features
>  - QMP stabilized
>    - 0.13.0 -> 0.14 QMP
>    - hard attempt not to break compatibility
>    - new commands, rework, async, human monitor passthrough
>    - goal getting to libvirt not needing human monitor at all
>    - QMP KVM autotest test suite submitted
> - in-kernel apic, tpr patching still outstanding
> - QED coroutine concurrency

Would it be realistic to declare deprecating the qemu-kvm fork for 0.14 as goal?

> Live snapshots
> - merge snapshot?
>  - already supported, question about mgmt of snapshot chain
> - integrate with fsfreeze (and windows alternative)
> 
> Guest Agent
> - have one coming RSN (poke Anthony for details)

Would there be a chance to have a single agent for everyone, so that we actually form a Qemu agent instead of a dozen individual ones? I'm mainly thinking Spice here.


Alex

Re: [Qemu-devel] KVM call minutes for Oct 19

[Paolo Bonzini]

On 10/20/2010 10:21 AM, Alexander Graf wrote:
> Would it be realistic to declare deprecating the qemu-kvm fork for
> 0.14 as goal?

I recall some performance problems with the qemu.git iothread, I'm not 
sure all of those have been fixed.

Paolo

Re: [Qemu-devel] KVM call minutes for Oct 19

[Alexander Graf]

On 20.10.2010, at 10:25, Paolo Bonzini wrote:

> On 10/20/2010 10:21 AM, Alexander Graf wrote:
>> Would it be realistic to declare deprecating the qemu-kvm fork for
>> 0.14 as goal?
> 
> I recall some performance problems with the qemu.git iothread, I'm not sure all of those have been fixed.

Yes, hence "declare as goal". Deprecating doesn't mean to declare it void, but to actually work towards eliminating all the shortcomings. Another thing coming to mind there is that the default -accel should be moved to kvm,tcg instead of only tcg as it stands today.


Alex

Re: [Qemu-devel] KVM call minutes for Oct 19

[Avi Kivity]

  On 10/20/2010 10:21 AM, Alexander Graf wrote:
> On 19.10.2010, at 17:14, Chris Wright wrote:
>
> >  0.13.X -stable
> >  - Anthony will send note to qemu-devel on this
> >  - move 0.13.X -stable to a separate tree
> >  - driven independently of main qemu tree
> >  - challenge is always in the porting and testing of backported fixes
> >  - looking for volunteers
> >
> >  0.14
> >  - would like to do this before end of the year
> >  - 0.13 forked off a while back (~July),
> >  - 0.14 features
> >   - QMP stabilized
> >     - 0.13.0 ->  0.14 QMP
> >     - hard attempt not to break compatibility
> >     - new commands, rework, async, human monitor passthrough
> >     - goal getting to libvirt not needing human monitor at all
> >     - QMP KVM autotest test suite submitted
> >  - in-kernel apic, tpr patching still outstanding
> >  - QED coroutine concurrency
>
> Would it be realistic to declare deprecating the qemu-kvm fork for 0.14 as goal?

For general use perhaps, device assignment might need another cycle.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] KVM call minutes for Oct 19

[Dor Laor]

On 10/20/2010 10:21 AM, Alexander Graf wrote:
>
> On 19.10.2010, at 17:14, Chris Wright wrote:
>
>> 0.13.X -stable
>> - Anthony will send note to qemu-devel on this
>> - move 0.13.X -stable to a separate tree
>> - driven independently of main qemu tree
>> - challenge is always in the porting and testing of backported fixes
>> - looking for volunteers
>>
>> 0.14
>> - would like to do this before end of the year
>> - 0.13 forked off a while back (~July),
>> - 0.14 features
>>   - QMP stabilized
>>     - 0.13.0 ->  0.14 QMP
>>     - hard attempt not to break compatibility
>>     - new commands, rework, async, human monitor passthrough
>>     - goal getting to libvirt not needing human monitor at all
>>     - QMP KVM autotest test suite submitted
>> - in-kernel apic, tpr patching still outstanding
>> - QED coroutine concurrency
>
> Would it be realistic to declare deprecating the qemu-kvm fork for 0.14 as goal?
>
>> Live snapshots
>> - merge snapshot?
>>   - already supported, question about mgmt of snapshot chain
>> - integrate with fsfreeze (and windows alternative)
>>
>> Guest Agent
>> - have one coming RSN (poke Anthony for details)
>
> Would there be a chance to have a single agent for everyone, so that we actually form a Qemu agent instead of a dozen individual ones? I'm mainly thinking Spice here.

More important than the number of instances is the usage of common 
framework. Here is the link to the Matahari project:
https://fedorahosted.org/matahari/wiki/API



>
>
> Alex
>
>

Re: [Qemu-devel] KVM call minutes for Oct 19

[Andrew Beekhof]

On 10/20/2010 02:16 PM, Dor Laor wrote:
> On 10/20/2010 10:21 AM, Alexander Graf wrote:
>>
>> On 19.10.2010, at 17:14, Chris Wright wrote:
>>> Guest Agent
>>> - have one coming RSN (poke Anthony for details)
>>
>> Would there be a chance to have a single agent for everyone, so that
>> we actually form a Qemu agent instead of a dozen individual ones? I'm
>> mainly thinking Spice here.
>
> More important than the number of instances is the usage of common
> framework. Here is the link to the Matahari project:
> https://fedorahosted.org/matahari/wiki/API

Hello from the Matahari tech-lead...
Is there any documentation on the capabilities provided guest agent 
Anthony is creating?  Perhaps we can combine efforts.

Also happy to provide more information on Matahari if anyone is interested.

-- Andrew

Re: [Qemu-devel] KVM call minutes for Oct 19

[Dor Laor]

On 10/21/2010 12:22 PM, Andrew Beekhof wrote:
> On 10/20/2010 02:16 PM, Dor Laor wrote:
>> On 10/20/2010 10:21 AM, Alexander Graf wrote:
>>>
>>> On 19.10.2010, at 17:14, Chris Wright wrote:
>>>> Guest Agent
>>>> - have one coming RSN (poke Anthony for details)
>>>
>>> Would there be a chance to have a single agent for everyone, so that
>>> we actually form a Qemu agent instead of a dozen individual ones? I'm
>>> mainly thinking Spice here.
>>
>> More important than the number of instances is the usage of common
>> framework. Here is the link to the Matahari project:
>> https://fedorahosted.org/matahari/wiki/API
>
> Hello from the Matahari tech-lead...
> Is there any documentation on the capabilities provided guest agent
> Anthony is creating? Perhaps we can combine efforts.

http://repo.or.cz/w/qemu/mdroth.git/tree

He said that they'll publish the info in a week.

>
> Also happy to provide more information on Matahari if anyone is interested.

Go ahead and supply it on upstream kvm-devel / qemu-devel list

>
> -- Andrew

Re: [Qemu-devel] KVM call minutes for Oct 19

[Anthony Liguori]

Hi Andrew,

On 10/21/2010 05:22 AM, Andrew Beekhof wrote:
>
> Hello from the Matahari tech-lead...
> Is there any documentation on the capabilities provided guest agent 
> Anthony is creating?  Perhaps we can combine efforts.

Mike should be posting today or tomorrow.

> Also happy to provide more information on Matahari if anyone is 
> interested.

I'd really like to hear more about Matahari's long term vision.

For a QEMU guest agent, we need something that is very portable.  The 
interfaces it provides need to be reasonably guest agnostic and we need 
to support a wide range of guests including Windows, Linux, *BSD, etc.

 From the little bit I've read about Matahari, it seems to be pretty 
specific and pretty oriented towards Fedora-like distributions.  It 
exposes interfaces for manipulation of RPM packages, relies on netcf, etc.

There's nothing wrong with this if the goal of Matahari is to provide a 
robust agent for Fedora-based Linux distributions but I don't think it 
meets the requirements of a QEMU guest agent.

I don't think we can overly optimize for one Linux distribution either 
so a mentality of letting other platforms contribute their own support 
probably won't work.

Regards,

Anthony Liguori

> -- Andrew
> -- 
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] KVM call minutes for Oct 19

[Daniel P. Berrange]

On Thu, Oct 21, 2010 at 08:09:44AM -0500, Anthony Liguori wrote:
> Hi Andrew,
> 
> On 10/21/2010 05:22 AM, Andrew Beekhof wrote:
> >
> >Hello from the Matahari tech-lead...
> >Is there any documentation on the capabilities provided guest agent 
> >Anthony is creating?  Perhaps we can combine efforts.
> 
> Mike should be posting today or tomorrow.
> 
> >Also happy to provide more information on Matahari if anyone is 
> >interested.
> 
> I'd really like to hear more about Matahari's long term vision.
> 
> For a QEMU guest agent, we need something that is very portable.  The 
> interfaces it provides need to be reasonably guest agnostic and we need 
> to support a wide range of guests including Windows, Linux, *BSD, etc.
> 
> From the little bit I've read about Matahari, it seems to be pretty 
> specific and pretty oriented towards Fedora-like distributions.  It 
> exposes interfaces for manipulation of RPM packages, relies on netcf, etc.

FYI netcf is not Fedora specific. There is a Win32 backend for it
too. It does need porting to other Linux distros, but that's simply
an internal implementation issue. The goal of netcf is to be the
libvirt of network config mgmt - a portable API for all OS network
config tasks. Further, Matahari itself is also being ported to Win32
and can be ported to other Linux distros too.

> There's nothing wrong with this if the goal of Matahari is to provide a 
> robust agent for Fedora-based Linux distributions but I don't think it 
> meets the requirements of a QEMU guest agent.
> 
> I don't think we can overly optimize for one Linux distribution either 
> so a mentality of letting other platforms contribute their own support 
> probably won't work.

That is not the goal of Matahari. It is intended to be generically
applicable to *all* guest OS. Obviously in areas where every distro
does different things, then it will need porting for each different
impl. You have to start somewhere and it started with Fedora. This
is all is true of any guest agent solution. 

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

Re: [Qemu-devel] KVM call minutes for Oct 19

[Anthony Liguori]

On 10/21/2010 08:18 AM, Daniel P. Berrange wrote:
> On Thu, Oct 21, 2010 at 08:09:44AM -0500, Anthony Liguori wrote:
>    
>> Hi Andrew,
>>
>> On 10/21/2010 05:22 AM, Andrew Beekhof wrote:
>>      
>>> Hello from the Matahari tech-lead...
>>> Is there any documentation on the capabilities provided guest agent
>>> Anthony is creating?  Perhaps we can combine efforts.
>>>        
>> Mike should be posting today or tomorrow.
>>
>>      
>>> Also happy to provide more information on Matahari if anyone is
>>> interested.
>>>        
>> I'd really like to hear more about Matahari's long term vision.
>>
>> For a QEMU guest agent, we need something that is very portable.  The
>> interfaces it provides need to be reasonably guest agnostic and we need
>> to support a wide range of guests including Windows, Linux, *BSD, etc.
>>
>>  From the little bit I've read about Matahari, it seems to be pretty
>> specific and pretty oriented towards Fedora-like distributions.  It
>> exposes interfaces for manipulation of RPM packages, relies on netcf, etc.
>>      
> FYI netcf is not Fedora specific. There is a Win32 backend for it
> too. It does need porting to other Linux distros, but that's simply
> an internal implementation issue. The goal of netcf is to be the
> libvirt of network config mgmt - a portable API for all OS network
> config tasks. Further, Matahari itself is also being ported to Win32
> and can be ported to other Linux distros too.
>    

Yeah, I'm aware of the goals of netcf but that hasn't materialized a 
port to other distros.

Let me be clear, I don't think this is a problem for libvirt, 
NetworkManager, or even Matahari.

But for a QEMU guest agent where we terminate the APIs within QEMU 
itself, I do think it creates a pretty nasty portability barrier.

>> There's nothing wrong with this if the goal of Matahari is to provide a
>> robust agent for Fedora-based Linux distributions but I don't think it
>> meets the requirements of a QEMU guest agent.
>>
>> I don't think we can overly optimize for one Linux distribution either
>> so a mentality of letting other platforms contribute their own support
>> probably won't work.
>>      
> That is not the goal of Matahari. It is intended to be generically
> applicable to *all* guest OS. Obviously in areas where every distro
> does different things, then it will need porting for each different
> impl. You have to start somewhere and it started with Fedora. This
> is all is true of any guest agent solution.
>    

There's two approaches that could be taken for a guest agent.  You could 
provide very low level interfaces (read a file, execute a command, read 
a registry key).  This makes for a very portable guest agent at the cost 
of complexity in interacting with the agent.  The agent doesn't ever 
really need to change much the client (QEMU) needs to handle many 
different types of guests, and add new functionality based on the 
supported primitives.

Another approach is to put the complexity in the agent and simplify the 
management interface.  For system's management applications, this is 
probably the right approach.  For virtualization, I think this is a bad 
approach.

Very specifically, netcf only really needs to read and write 
configuration files and potentially run a command.  Instead of linking 
against netcf in the guest, we should link against netcf in QEMU so that 
we don't have to constantly change the guest agent.

Regards,

Anthony Liguori


> Regards,
> Daniel
>    

Re: [Qemu-devel] KVM call minutes for Oct 19

[Andrew Beekhof]

On 10/21/2010 03:32 PM, Anthony Liguori wrote:
> On 10/21/2010 08:18 AM, Daniel P. Berrange wrote:
>> On Thu, Oct 21, 2010 at 08:09:44AM -0500, Anthony Liguori wrote:
>>> Hi Andrew,
>>>
>>> On 10/21/2010 05:22 AM, Andrew Beekhof wrote:
>>>> Hello from the Matahari tech-lead...
>>>> Is there any documentation on the capabilities provided guest agent
>>>> Anthony is creating? Perhaps we can combine efforts.
>>> Mike should be posting today or tomorrow.
>>>
>>>> Also happy to provide more information on Matahari if anyone is
>>>> interested.
>>> I'd really like to hear more about Matahari's long term vision.
>>>
>>> For a QEMU guest agent, we need something that is very portable. The
>>> interfaces it provides need to be reasonably guest agnostic and we need
>>> to support a wide range of guests including Windows, Linux, *BSD, etc.
>>>
>>> From the little bit I've read about Matahari, it seems to be pretty
>>> specific and pretty oriented towards Fedora-like distributions.

In that case we've done a bad job of the wiki.
Windows and other distributions are a key part of the Matahari vision.

Matahari is two things
- an architecture, and
- an implementation of the most common API sets

Each set of APIs (ie. host, network, services) is an independent 
daemon/agent which attaches to a common QMF broker (more on that later).

While some of these might be platform specific, packaging would be one 
likely candidate, the intention is to be agnostic distro/platform 
wherever possible.

Take netcf for example, instead of re-inventing the wheel we wrote the 
windows port for netcf.


So what's this about QMF you ask?
Again, rather than invent our own message protocol we're leveraging an 
existing standard that supports windows and linux, is fast, reliable and 
secure.

Its also pluggable and discoverable - so simply starting a new agent 
that connects to the matahari broker makes it's API available.  Any QMF 
client/console can also interrogate the guest to see what agents and API 
calls are available.

Even better there's going to be a virtio-serial transport.  So we can 
access the same agents in the same way with or without host-to-guest 
networking.  This was a key requirement for us because of EC2-like cloud 
scenarios where we don't have access to the physical host.


Thats probably enough for the moment, I'd better go make dinner :-)


>>> It
>>> exposes interfaces for manipulation of RPM packages, relies on netcf,
>>> etc.
>> FYI netcf is not Fedora specific. There is a Win32 backend for it
>> too. It does need porting to other Linux distros, but that's simply
>> an internal implementation issue. The goal of netcf is to be the
>> libvirt of network config mgmt - a portable API for all OS network
>> config tasks. Further, Matahari itself is also being ported to Win32
>> and can be ported to other Linux distros too.
>
> Yeah, I'm aware of the goals of netcf but that hasn't materialized a
> port to other distros.
>
> Let me be clear, I don't think this is a problem for libvirt,
> NetworkManager, or even Matahari.
>
> But for a QEMU guest agent where we terminate the APIs within QEMU
> itself, I do think it creates a pretty nasty portability barrier.
>
>>> There's nothing wrong with this if the goal of Matahari is to provide a
>>> robust agent for Fedora-based Linux distributions but I don't think it
>>> meets the requirements of a QEMU guest agent.
>>>
>>> I don't think we can overly optimize for one Linux distribution either
>>> so a mentality of letting other platforms contribute their own support
>>> probably won't work.
>> That is not the goal of Matahari. It is intended to be generically
>> applicable to *all* guest OS. Obviously in areas where every distro
>> does different things, then it will need porting for each different
>> impl. You have to start somewhere and it started with Fedora. This
>> is all is true of any guest agent solution.
>
> There's two approaches that could be taken for a guest agent. You could
> provide very low level interfaces (read a file, execute a command, read
> a registry key). This makes for a very portable guest agent at the cost
> of complexity in interacting with the agent. The agent doesn't ever
> really need to change much the client (QEMU) needs to handle many
> different types of guests, and add new functionality based on the
> supported primitives.
>
> Another approach is to put the complexity in the agent and simplify the
> management interface. For system's management applications, this is
> probably the right approach. For virtualization, I think this is a bad
> approach.
>
> Very specifically, netcf only really needs to read and write
> configuration files and potentially run a command. Instead of linking
> against netcf in the guest, we should link against netcf in QEMU so that
> we don't have to constantly change the guest agent.
>
> Regards,
>
> Anthony Liguori
>
>
>> Regards,
>> Daniel
>
>

Re: [Qemu-devel] KVM call minutes for Oct 19

[Anthony Liguori]

Hi Andrew,

On 10/21/2010 10:43 AM, Andrew Beekhof wrote:
> In that case we've done a bad job of the wiki.
> Windows and other distributions are a key part of the Matahari vision.
>
> Matahari is two things
> - an architecture, and
> - an implementation of the most common API sets
>
> Each set of APIs (ie. host, network, services) is an independent 
> daemon/agent which attaches to a common QMF broker (more on that later).
>
> While some of these might be platform specific, packaging would be one 
> likely candidate, the intention is to be agnostic distro/platform 
> wherever possible.
>
> Take netcf for example, instead of re-inventing the wheel we wrote the 
> windows port for netcf.
>
>
> So what's this about QMF you ask?
> Again, rather than invent our own message protocol we're leveraging an 
> existing standard that supports windows and linux, is fast, reliable 
> and secure.
>
> Its also pluggable and discoverable - so simply starting a new agent 
> that connects to the matahari broker makes it's API available.  Any 
> QMF client/console can also interrogate the guest to see what agents 
> and API calls are available.
>
> Even better there's going to be a virtio-serial transport.  So we can 
> access the same agents in the same way with or without host-to-guest 
> networking.  This was a key requirement for us because of EC2-like 
> cloud scenarios where we don't have access to the physical host.

I did get this much and I think I'm doing a poor job explaining myself.

I think Matahari is tackling the same space that many other frameworks 
are.  For instance, everything you say above is (supposed to be) true 
for something like OpenWBEM, Pegasus, etc.

The advantage I see in Matahari is that 1) it can take advantage of 
virtio-serial 2) it's significantly lighter than CIM 3) it's community 
driven.

So there's no doubt in my mind that if you need a way to inventory 
physical and virtual systems, something like Matahari becomes a very 
appealing option to do that.

But that's not the problem space I'm trying to tackle.

An example of the problem I'm trying to tackle is guest reboot.

On x86, there is no ACPI interface for requesting a guest reboot.  Other 
platforms do provide this and we usually try to emulate platform 
interfaces whenever possible.  In order to implement host-initiated 
reboot (aka virDomainReboot) we need to have a mechanism to execute the 
reboot command in the guest that's initiated by the hypervisor.

This is not the same thing as a remote system's management interface.  
This is something that should be dead-simple and trivially portable.

I think there's symbiotic relationship that a QEMU-based guest agent 
could play with a Matahari based agent.  But my initial impression is 
that the types of problems we're trying to tackle are fundamentally 
different than the problem that Matahari is even if it superficially 
appears like there's an overlap.

For instance, communication window locations to enable "coherence" mode 
in the QEMU GUI is something that makes no sense as a network management 
interface.  This is something that only makes sense between QEMU and the 
guest agent.

Regards,

Anthony Liguori

>
> Thats probably enough for the moment, I'd better go make dinner :-)
>
>
>>>> It
>>>> exposes interfaces for manipulation of RPM packages, relies on netcf,
>>>> etc.
>>> FYI netcf is not Fedora specific. There is a Win32 backend for it
>>> too. It does need porting to other Linux distros, but that's simply
>>> an internal implementation issue. The goal of netcf is to be the
>>> libvirt of network config mgmt - a portable API for all OS network
>>> config tasks. Further, Matahari itself is also being ported to Win32
>>> and can be ported to other Linux distros too.
>>
>> Yeah, I'm aware of the goals of netcf but that hasn't materialized a
>> port to other distros.
>>
>> Let me be clear, I don't think this is a problem for libvirt,
>> NetworkManager, or even Matahari.
>>
>> But for a QEMU guest agent where we terminate the APIs within QEMU
>> itself, I do think it creates a pretty nasty portability barrier.
>>
>>>> There's nothing wrong with this if the goal of Matahari is to 
>>>> provide a
>>>> robust agent for Fedora-based Linux distributions but I don't think it
>>>> meets the requirements of a QEMU guest agent.
>>>>
>>>> I don't think we can overly optimize for one Linux distribution either
>>>> so a mentality of letting other platforms contribute their own support
>>>> probably won't work.
>>> That is not the goal of Matahari. It is intended to be generically
>>> applicable to *all* guest OS. Obviously in areas where every distro
>>> does different things, then it will need porting for each different
>>> impl. You have to start somewhere and it started with Fedora. This
>>> is all is true of any guest agent solution.
>>
>> There's two approaches that could be taken for a guest agent. You could
>> provide very low level interfaces (read a file, execute a command, read
>> a registry key). This makes for a very portable guest agent at the cost
>> of complexity in interacting with the agent. The agent doesn't ever
>> really need to change much the client (QEMU) needs to handle many
>> different types of guests, and add new functionality based on the
>> supported primitives.
>>
>> Another approach is to put the complexity in the agent and simplify the
>> management interface. For system's management applications, this is
>> probably the right approach. For virtualization, I think this is a bad
>> approach.
>>
>> Very specifically, netcf only really needs to read and write
>> configuration files and potentially run a command. Instead of linking
>> against netcf in the guest, we should link against netcf in QEMU so that
>> we don't have to constantly change the guest agent.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>
>>> Regards,
>>> Daniel
>>
>>
>

Re: [Qemu-devel] KVM call minutes for Oct 19

[Chris Wright]

* Anthony Liguori (anthony@codemonkey.ws) wrote:
> So there's no doubt in my mind that if you need a way to inventory
> physical and virtual systems, something like Matahari becomes a very
> appealing option to do that.
> 
> But that's not the problem space I'm trying to tackle.
> 
> An example of the problem I'm trying to tackle is guest reboot.

Matahari already has shutdown and reboot methods.

Inventory, reboot, filesystem freeze, cut'n paste, etc.. all are
communicating between host and guest.  Main point is to consolidate
effort to keep from having some sprawl of agents (which agent do I
install to do reboot?).

thanks,
-chris

Re: [Qemu-devel] KVM call minutes for Oct 19

[Andrew Beekhof]

On 10/21/2010 06:25 PM, Anthony Liguori wrote:
> Hi Andrew,
>
> On 10/21/2010 10:43 AM, Andrew Beekhof wrote:
>> In that case we've done a bad job of the wiki.
>> Windows and other distributions are a key part of the Matahari vision.
>>
>> Matahari is two things
>> - an architecture, and
>> - an implementation of the most common API sets
>>
>> Each set of APIs (ie. host, network, services) is an independent
>> daemon/agent which attaches to a common QMF broker (more on that later).
>>
>> While some of these might be platform specific, packaging would be one
>> likely candidate, the intention is to be agnostic distro/platform
>> wherever possible.
>>
>> Take netcf for example, instead of re-inventing the wheel we wrote the
>> windows port for netcf.
>>
>>
>> So what's this about QMF you ask?
>> Again, rather than invent our own message protocol we're leveraging an
>> existing standard that supports windows and linux, is fast, reliable
>> and secure.
>>
>> Its also pluggable and discoverable - so simply starting a new agent
>> that connects to the matahari broker makes it's API available. Any QMF
>> client/console can also interrogate the guest to see what agents and
>> API calls are available.
>>
>> Even better there's going to be a virtio-serial transport. So we can
>> access the same agents in the same way with or without host-to-guest
>> networking. This was a key requirement for us because of EC2-like
>> cloud scenarios where we don't have access to the physical host.
>
> I did get this much and I think I'm doing a poor job explaining myself.
>
> I think Matahari is tackling the same space that many other frameworks
> are. For instance, everything you say above is (supposed to be) true for
> something like OpenWBEM, Pegasus, etc.

I think the scope is also different.
Our focus is on satisfying concrete needs rather than nebulous 
all-encompassing goals.

>
> The advantage I see in Matahari is that 1) it can take advantage of
> virtio-serial 2) it's significantly lighter than CIM 3) it's community
> driven.
>
> So there's no doubt in my mind that if you need a way to inventory
> physical and virtual systems, something like Matahari becomes a very
> appealing option to do that.
>
> But that's not the problem space I'm trying to tackle.

Neither are we really.

I came to Matahari came from clustering (I wrote Pacemaker), so service 
management is my original area of interest.

But for the sake of argument, assume inventory was our sole focus.
There is, by design, a place in the architecture for third-party agents.

Just because the agent wasn't built from matahari.git doesn't mean it 
can't make use of "our" bus.

> An example of the problem I'm trying to tackle is guest reboot.

Reboot was one of the first things we implemented :-)

>
> On x86, there is no ACPI interface for requesting a guest reboot. Other
> platforms do provide this and we usually try to emulate platform
> interfaces whenever possible. In order to implement host-initiated
> reboot (aka virDomainReboot) we need to have a mechanism to execute the
> reboot command in the guest that's initiated by the hypervisor.
>
> This is not the same thing as a remote system's management interface.
> This is something that should be dead-simple and trivially portable.
>
> I think there's symbiotic relationship that a QEMU-based guest agent
> could play with a Matahari based agent. But my initial impression is
> that the types of problems we're trying to tackle are fundamentally
> different than the problem that Matahari is

Honestly, we're interested in whatever the teams that want to work with 
us are interested in.  Our primary mission is to consolidate common 
functionality and avoid N implementations of essentially the same thing.

And I suspect that many people would be interested in having what you're 
working on exposed remotely.


So if you'd like to do this agent as part of Matahari, great.
But if you want to keep it separate and just want to leverage the 
design, that also not a problem.

Or if the core functionality was in a library, we'd happily write the 
glue to make it accessible via QMF and dbus.

There's really a number of levels on which we could work together - if 
you're interested.

Re: [Qemu-devel] KVM call minutes for Oct 19

[Anthony Liguori]

On 10/20/2010 03:21 AM, Alexander Graf wrote:
>> Live snapshots
>> - merge snapshot?
>>   - already supported, question about mgmt of snapshot chain
>> - integrate with fsfreeze (and windows alternative)
>>
>> Guest Agent
>> - have one coming RSN (poke Anthony for details)
>>      
> Would there be a chance to have a single agent for everyone, so that we actually form a Qemu agent instead of a dozen individual ones? I'm mainly thinking Spice here.
>    

Our main design points are to keep the code simple with few dependencies 
and to provide interfaces that have the maximum amount of flexibility.

Having a single agent (not an agent framework) is important if we want 
these interfaces to be ubiquitous.  This really means that the guest 
agent should be part of the QEMU source tree IMHO so that there is 
always a standard version of the agent.

Regards,

Anthony Liguori

> Alex
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: [Qemu-devel] KVM call minutes for Oct 19

[Daniel P. Berrange]

On Wed, Oct 20, 2010 at 08:02:07AM -0500, Anthony Liguori wrote:
> On 10/20/2010 03:21 AM, Alexander Graf wrote:
> >>Live snapshots
> >>- merge snapshot?
> >>  - already supported, question about mgmt of snapshot chain
> >>- integrate with fsfreeze (and windows alternative)
> >>
> >>Guest Agent
> >>- have one coming RSN (poke Anthony for details)
> >>     
> >Would there be a chance to have a single agent for everyone, so that we 
> >actually form a Qemu agent instead of a dozen individual ones? I'm mainly 
> >thinking Spice here.
> >   
> 
> Our main design points are to keep the code simple with few dependencies 
> and to provide interfaces that have the maximum amount of flexibility.
> 
> Having a single agent (not an agent framework) is important if we want 
> these interfaces to be ubiquitous.  This really means that the guest 
> agent should be part of the QEMU source tree IMHO so that there is 
> always a standard version of the agent.

The thinking with Matahari is that there is significant overlap between
agent requirements for a physical and virtual host, so it aims to provide
an agent that works everywhere, whether virtualized or not. All that need
change is the communication transport (TCP vs VirtIO Serial vs legacy
serial vs some other data channel), and enable/disable certain agent
services according to deployment scenario. Once you go to a more general
purpose agent in this way, then it doesn't make such sense to put it all
in the QEMU tree.

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

Re: [Qemu-devel] KVM call minutes for Oct 19

[Anthony Liguori]

On 10/20/2010 08:19 AM, Daniel P. Berrange wrote:
> The thinking with Matahari is that there is significant overlap between
> agent requirements for a physical and virtual host, so it aims to provide
> an agent that works everywhere, whether virtualized or not. All that need
> change is the communication transport (TCP vs VirtIO Serial vs legacy
> serial vs some other data channel), and enable/disable certain agent
> services according to deployment scenario. Once you go to a more general
> purpose agent in this way, then it doesn't make such sense to put it all
> in the QEMU tree.
>    

Actually, I don't think we want to have a common agent for physical and 
virtual systems.

The requirements are actually very different.  The virtual agent exists 
solely to support hypervisor functionality.  Not to provide general 
purpose system management support.

Regards,

Anthony Liguori

> Regards,
> Daniel
>    

Re: [Qemu-devel] KVM call minutes for Oct 19

[Dor Laor]

On 10/20/2010 03:21 PM, Anthony Liguori wrote:
> On 10/20/2010 08:19 AM, Daniel P. Berrange wrote:
>> The thinking with Matahari is that there is significant overlap between
>> agent requirements for a physical and virtual host, so it aims to provide
>> an agent that works everywhere, whether virtualized or not. All that need
>> change is the communication transport (TCP vs VirtIO Serial vs legacy
>> serial vs some other data channel), and enable/disable certain agent
>> services according to deployment scenario. Once you go to a more general
>> purpose agent in this way, then it doesn't make such sense to put it all
>> in the QEMU tree.
>
> Actually, I don't think we want to have a common agent for physical and
> virtual systems.
>
> The requirements are actually very different. The virtual agent exists
> solely to support hypervisor functionality. Not to provide general
> purpose system management support.

True although there is much in common and there are several api for 
hypervisor only. I think it's sensible to ask for such.

IMHO we can't put the complete guest agent code in qemu:
   - There would be OS specific code like windows and windows only
     interfaces (WMI)
   - Agents can benefits from guest frameworks like dbus. Will we take
     dbus into qemu or re-write it ourselves?

I agree that some agent code for basic stuff like live snapshot sync 
with the filesystem is small enough and worth to host within qemu.
Maybe we do need more than one project?

>
> Regards,
>
> Anthony Liguori
>
>> Regards,
>> Daniel
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] KVM call minutes for Oct 19

[Alexander Graf]

Am 21.10.2010 um 00:46 schrieb Dor Laor <dlaor@redhat.com>:

> On 10/20/2010 03:21 PM, Anthony Liguori wrote:
>> On 10/20/2010 08:19 AM, Daniel P. Berrange wrote:
>>> The thinking with Matahari is that there is significant overlap between
>>> agent requirements for a physical and virtual host, so it aims to provide
>>> an agent that works everywhere, whether virtualized or not. All that need
>>> change is the communication transport (TCP vs VirtIO Serial vs legacy
>>> serial vs some other data channel), and enable/disable certain agent
>>> services according to deployment scenario. Once you go to a more general
>>> purpose agent in this way, then it doesn't make such sense to put it all
>>> in the QEMU tree.
>> 
>> Actually, I don't think we want to have a common agent for physical and
>> virtual systems.
>> 
>> The requirements are actually very different. The virtual agent exists
>> solely to support hypervisor functionality. Not to provide general
>> purpose system management support.
> 
> True although there is much in common and there are several api for hypervisor only. I think it's sensible to ask for such.

I'm not sure it's worth the inflexibility.

> 
> IMHO we can't put the complete guest agent code in qemu:
>  - There would be OS specific code like windows and windows only
>    interfaces (WMI)
>  - Agents can benefits from guest frameworks like dbus. Will we take
>    dbus into qemu or re-write it ourselves?

I don't understand the argument. We have plenty of binary blobs in qemu. Why not gave the guest agent be one of them, having the source in the qemu tree nevertheless?

> 
> I agree that some agent code for basic stuff like live snapshot sync with the filesystem is small enough and worth to host within qemu.
> Maybe we do need more than one project?
> 

No, please. That's exactly what I don't want to see. The libvirt/qemu/virt-man split is killing us already. How is this going to become with 20 driver packs for the guest?

Alex

>> 

Re: [Qemu-devel] KVM call minutes for Oct 19

[Paolo Bonzini]

On 10/21/2010 03:14 AM, Alexander Graf wrote:
>> I agree that some agent code for basic stuff like live snapshot
>> sync with the filesystem is small enough and worth to host within
>> qemu. Maybe we do need more than one project?
>
> No, please. That's exactly what I don't want to see. The
> libvirt/qemu/virt-man split is killing us already. How is this going
> to become with 20 driver packs for the guest?

Agreed.  Not relying on Mata Hari and reinventing a dbus/WMI interface 
would be yet another case of QEMU NIH.  The same argument also works on 
the backend BTW, it can be virtio serial but also a Xen pvconsole and 
that wheel should not be reinvented either.

The guest agent should be a pluggable architecture, and QEMU can provide 
plugins for sync, spice, "info balloon" and everything else it needs.

Paolo

Re: [Qemu-devel] KVM call minutes for Oct 19

[Anthony Liguori]

On 10/21/2010 02:45 AM, Paolo Bonzini wrote:
> On 10/21/2010 03:14 AM, Alexander Graf wrote:
>>> I agree that some agent code for basic stuff like live snapshot
>>> sync with the filesystem is small enough and worth to host within
>>> qemu. Maybe we do need more than one project?
>>
>> No, please. That's exactly what I don't want to see. The
>> libvirt/qemu/virt-man split is killing us already. How is this going
>> to become with 20 driver packs for the guest?
>
> Agreed.  Not relying on Mata Hari and reinventing a dbus/WMI interface 
> would be yet another case of QEMU NIH.

I think we're about 10 steps ahead of where we should be right now.

The first step is just identifying what interfaces we need in a guest 
agent.  So far, I think we can get away with a very small number of 
interfaces (mainly read/write files, execute command).

>   The same argument also works on the backend BTW, it can be virtio 
> serial but also a Xen pvconsole and that wheel should not be 
> reinvented either.
>
> The guest agent should be a pluggable architecture, and QEMU can 
> provide plugins for sync, spice, "info balloon" and everything else it 
> needs.

virtio-serial is essentially our plugin interface.  The core QEMU agent 
would use org.qemu.guest-agent and a spice against could use 
org.spice-space.guest-agent.

The QEMU agent should have an interface that terminates in QEMU itself.

Regards,

Anthony Liguori

> Paolo

Re: [Qemu-devel] KVM call minutes for Oct 19

[Dor Laor]

On 10/21/2010 03:02 PM, Anthony Liguori wrote:
> On 10/21/2010 02:45 AM, Paolo Bonzini wrote:
>> On 10/21/2010 03:14 AM, Alexander Graf wrote:
>>>> I agree that some agent code for basic stuff like live snapshot
>>>> sync with the filesystem is small enough and worth to host within
>>>> qemu. Maybe we do need more than one project?
>>>
>>> No, please. That's exactly what I don't want to see. The
>>> libvirt/qemu/virt-man split is killing us already. How is this going
>>> to become with 20 driver packs for the guest?
>>
>> Agreed. Not relying on Mata Hari and reinventing a dbus/WMI interface
>> would be yet another case of QEMU NIH.
>
> I think we're about 10 steps ahead of where we should be right now.
>
> The first step is just identifying what interfaces we need in a guest
> agent. So far, I think we can get away with a very small number of
> interfaces (mainly read/write files, execute command).
>
>> The same argument also works on the backend BTW, it can be virtio
>> serial but also a Xen pvconsole and that wheel should not be
>> reinvented either.
>>
>> The guest agent should be a pluggable architecture, and QEMU can
>> provide plugins for sync, spice, "info balloon" and everything else it
>> needs.
>
> virtio-serial is essentially our plugin interface. The core QEMU agent
> would use org.qemu.guest-agent and a spice against could use
> org.spice-space.guest-agent.
>
> The QEMU agent should have an interface that terminates in QEMU itself.

I agree that for some think with semi-transaction oriented actions like 
the fs-freeze on live snapshot, we need a small, self confined code base.

>
> Regards,
>
> Anthony Liguori
>
>> Paolo
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] KVM call minutes for Oct 19

[Chris Wright]

* Anthony Liguori (anthony@codemonkey.ws) wrote:
> The first step is just identifying what interfaces we need in a
> guest agent.  So far, I think we can get away with a very small
> number of interfaces (mainly read/write files, execute command).

Could you elaborate here?  I can't imagine you mean:

vm_system(target_vm, "shutdown -r now")

But from other post, it does seem you want complexity in the host side
not guest side of agent.

Seems vm_reboot(target_vm) as the RPC makes more sense with the guest
side implementing that in whatever guest-specific appropriate way.

thanks,
-chris

Re: [Qemu-devel] KVM call minutes for Oct 19

[Anthony Liguori]

On 10/22/2010 12:29 PM, Chris Wright wrote:
> * Anthony Liguori (anthony@codemonkey.ws) wrote:
>    
>> The first step is just identifying what interfaces we need in a
>> guest agent.  So far, I think we can get away with a very small
>> number of interfaces (mainly read/write files, execute command).
>>      
> Could you elaborate here?  I can't imagine you mean:
>
> vm_system(target_vm, "shutdown -r now")
>
> But from other post, it does seem you want complexity in the host side
> not guest side of agent.
>
> Seems vm_reboot(target_vm) as the RPC makes more sense with the guest
> side implementing that in whatever guest-specific appropriate way.
>    

What I really want is a vm_system API that a guest agent MUST implement 
and then APIs like vm_reboot that a guest agent MAY implement.

In my mind, the guest agent lives in the distros even though it's built 
from QEMU source tree.  We don't install it ourselves.

That means we might have a new funky fresh version of Fedora 21 version 
of QEMU but running an old Fedora 14 guest with a really back-level 
guest agent.

Having very low level APIs with logic that primarily lives in QEMU gives 
us the ability to support new features in QEMU with older guests.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Oct 19

[Chris Wright]

* Anthony Liguori (anthony@codemonkey.ws) wrote:
> On 10/22/2010 12:29 PM, Chris Wright wrote:
> >* Anthony Liguori (anthony@codemonkey.ws) wrote:
> >>The first step is just identifying what interfaces we need in a
> >>guest agent.  So far, I think we can get away with a very small
> >>number of interfaces (mainly read/write files, execute command).
> >Could you elaborate here?  I can't imagine you mean:
> >
> >vm_system(target_vm, "shutdown -r now")
> >
> >But from other post, it does seem you want complexity in the host side
> >not guest side of agent.
> >
> >Seems vm_reboot(target_vm) as the RPC makes more sense with the guest
> >side implementing that in whatever guest-specific appropriate way.
> 
> What I really want is a vm_system API that a guest agent MUST
> implement and then APIs like vm_reboot that a guest agent MAY
> implement.
> 
> In my mind, the guest agent lives in the distros even though it's
> built from QEMU source tree.  We don't install it ourselves.
> 
> That means we might have a new funky fresh version of Fedora 21
> version of QEMU but running an old Fedora 14 guest with a really
> back-level guest agent.
> 
> Having very low level APIs with logic that primarily lives in QEMU
> gives us the ability to support new features in QEMU with older
> guests.

I'm not sure about that.  That same new shiny Fedora 21 QEMU has no idea
what the right OS specific command to run in guest is.  Granted, it's
not likely that "reboot" or "shutdown -r now" are likely to change for
Linux guests, do we assume cygwin for Windows guests?  Really seems to
make more sense to have a stable ABI and negotiate version.

Also, from the point of view of a cloud where a VM agent is awfully
close to provider having backdoor into VM...a freeform vm_system()
doesn't seem like it'd be real popular.

thanks,
-chris

Re: [Qemu-devel] KVM call minutes for Oct 19

[Anthony Liguori]

On 10/22/2010 01:20 PM, Chris Wright wrote:
> * Anthony Liguori (anthony@codemonkey.ws) wrote:
>    
>> On 10/22/2010 12:29 PM, Chris Wright wrote:
>>      
>>> * Anthony Liguori (anthony@codemonkey.ws) wrote:
>>>        
>>>> The first step is just identifying what interfaces we need in a
>>>> guest agent.  So far, I think we can get away with a very small
>>>> number of interfaces (mainly read/write files, execute command).
>>>>          
>>> Could you elaborate here?  I can't imagine you mean:
>>>
>>> vm_system(target_vm, "shutdown -r now")
>>>
>>> But from other post, it does seem you want complexity in the host side
>>> not guest side of agent.
>>>
>>> Seems vm_reboot(target_vm) as the RPC makes more sense with the guest
>>> side implementing that in whatever guest-specific appropriate way.
>>>        
>> What I really want is a vm_system API that a guest agent MUST
>> implement and then APIs like vm_reboot that a guest agent MAY
>> implement.
>>
>> In my mind, the guest agent lives in the distros even though it's
>> built from QEMU source tree.  We don't install it ourselves.
>>
>> That means we might have a new funky fresh version of Fedora 21
>> version of QEMU but running an old Fedora 14 guest with a really
>> back-level guest agent.
>>
>> Having very low level APIs with logic that primarily lives in QEMU
>> gives us the ability to support new features in QEMU with older
>> guests.
>>      
> I'm not sure about that.  That same new shiny Fedora 21 QEMU has no idea
> what the right OS specific command to run in guest is.  Granted, it's
> not likely that "reboot" or "shutdown -r now" are likely to change for
> Linux guests, do we assume cygwin for Windows guests?

No, but I'll waive my hands and say that I'm sure Windows has some 
appropriate mechanism to do the same thing (like PowerShell).

>    Really seems to
> make more sense to have a stable ABI and negotiate version.
>    

I guess the point is: we can always teach QEMU about how to work around 
older guests.  We (usually) can't control the software that's present on 
the guest itself.

The more logic we have in QEMU, the less we have to change the software 
in the guest which means the more likely things will work.

> Also, from the point of view of a cloud where a VM agent is awfully
> close to provider having backdoor into VM...a freeform vm_system()
> doesn't seem like it'd be real popular.
>    

This is the best (irrational) argument against this practice.  
Obviously, there's no real security concern here, but the end-user view 
may be troubling.

That said, VMware has an interface for exactly this at least it's an 
established practice.

Regards,

Anthony Liguori

> thanks,
> -chris
>    

Re: [Qemu-devel] KVM call minutes for Oct 19

[Chris Wright]

* Anthony Liguori (anthony@codemonkey.ws) wrote:
> On 10/22/2010 01:20 PM, Chris Wright wrote:
> >I'm not sure about that.  That same new shiny Fedora 21 QEMU has no idea
> >what the right OS specific command to run in guest is.  Granted, it's
> >not likely that "reboot" or "shutdown -r now" are likely to change for
> >Linux guests, do we assume cygwin for Windows guests?
> 
> No, but I'll waive my hands and say that I'm sure Windows has some
> appropriate mechanism to do the same thing (like PowerShell).

OK (bleh), but it's still specific to the guest OS.

> >   Really seems to
> >make more sense to have a stable ABI and negotiate version.
> 
> I guess the point is: we can always teach QEMU about how to work
> around older guests.  We (usually) can't control the software that's
> present on the guest itself.

I don't understand why we'd work around an older guest if the host <->
guest interface is stable.  Sure it can be extended, but old interfaces
should keep on Just Working (TM).

> The more logic we have in QEMU, the less we have to change the
> software in the guest which means the more likely things will work.

Maybe you're saying the advantage of injecting the raw commands into
the guest is that a host rev will automagically give an old guest new
functionality?

> >Also, from the point of view of a cloud where a VM agent is awfully
> >close to provider having backdoor into VM...a freeform vm_system()
> >doesn't seem like it'd be real popular.
> 
> This is the best (irrational) argument against this practice.
> Obviously, there's no real security concern here, but the end-user
> view may be troubling.

Heh, cloud + security == irrational fear, basic axiom

> That said, VMware has an interface for exactly this at least it's an
> established practice.

OK, what about other bits of API?  I recall seeing things like cut'n
paste, reboot, ballooning, time, few bits that spice would care about...
Are you thinking that as well, or all in terms of read/write/exec?

thanks,
-chris