From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3XkK-0000DJ-IZ for qemu-devel@nongnu.org; Mon, 20 Aug 2012 15:34:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3XkJ-0001ue-FE for qemu-devel@nongnu.org; Mon, 20 Aug 2012 15:34:44 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:54332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3XkJ-0001uL-Ag for qemu-devel@nongnu.org; Mon, 20 Aug 2012 15:34:43 -0400 Received: by obbta14 with SMTP id ta14so9636520obb.4 for ; Mon, 20 Aug 2012 12:34:42 -0700 (PDT) Sender: fluxion Date: Mon, 20 Aug 2012 14:34:34 -0500 From: Michael Roth Message-ID: <20120820193434.GN16157@illuin> References: <1345223489.7008.YahooMailNeo@web122203.mail.ne1.yahoo.com> <20120820105429.5766948f@doriath.home> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120820105429.5766948f@doriath.home> Subject: Re: [Qemu-devel] qemu-ga : Guest Agent : Windows 2008 : Unknown command guest-fsfreeze-freeze List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: desi babu , "qemu-devel@nongnu.org" On Mon, Aug 20, 2012 at 10:54:29AM -0300, Luiz Capitulino wrote: > On Fri, 17 Aug 2012 10:11:29 -0700 (PDT) > desi babu wrote: > > > Guest-Agent : Windows 2008 Error : Relase 1.1.90 > > > > error : internal error unable to execute QEMU command 'guest-fsfreeze-freeze': this feature or command is not currently supported. > > That's correct, fsfreze is not supported on Windows. > > > Guest-info shows the command is available.  Is there any information available on the list of commands supported inside Windows ? Appreciate if you have any pointers. > > That's a qemu-ga bug. CC'ing Michael to check if he has a fix in mind for this. > I've been thinking about this one for a while. It's considered expected behavior, but I realize it sucks for discoverability. I doubt we want to do platform-specific QAPI schema definitions, so the only option I can think of is some kind of [de-]registration mechanism where we can mark commands as being not available for a particular build/platform in the cases where we stub out command implementations. I think we can expose this to existing clients by no longer listing commands marked as unsupported in the list provided by the guest-info command. It should "just work". Can probably do it for 1.3. For now, clients will have to catch it in the error-handling path.