From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call minutes for Oct 19 Date: Fri, 22 Oct 2010 12:39:33 -0500 Message-ID: <4CC1CC55.2040700@codemonkey.ws> References: <20101019151441.GA24673@x200.localdomain> <4DE00079-05FA-40DF-9EA5-9573AD745117@suse.de> <4CBEE84F.7060207@codemonkey.ws> <20101020131925.GH15143@redhat.com> <4CBEECE6.8030605@codemonkey.ws> <4CBF7154.2070304@redhat.com> <9DABD2D4-389E-4D05-8A4C-2DE1E20D3B5C@suse.de> <4CBFEF95.9060703@redhat.com> <4CC039DA.5090607@codemonkey.ws> <20101022172916.GF27794@x200.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , Alexander Graf , "dlaor@redhat.com" , "Daniel P. Berrange" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" To: Chris Wright Return-path: Received: from mail-gy0-f174.google.com ([209.85.160.174]:62739 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755694Ab0JVRjX (ORCPT ); Fri, 22 Oct 2010 13:39:23 -0400 Received: by gyg4 with SMTP id 4so833473gyg.19 for ; Fri, 22 Oct 2010 10:39:22 -0700 (PDT) In-Reply-To: <20101022172916.GF27794@x200.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: 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