From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LLTQZ-0001TR-LS for qemu-devel@nongnu.org; Fri, 09 Jan 2009 21:18:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LLTQX-0001TF-0D for qemu-devel@nongnu.org; Fri, 09 Jan 2009 21:18:18 -0500 Received: from [199.232.76.173] (port=49542 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLTQW-0001TC-Qt for qemu-devel@nongnu.org; Fri, 09 Jan 2009 21:18:16 -0500 Received: from mail2.shareable.org ([80.68.89.115]:59674) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LLTQW-0001l8-CH for qemu-devel@nongnu.org; Fri, 09 Jan 2009 21:18:16 -0500 Date: Sat, 10 Jan 2009 02:18:11 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] mark nic as trusted Message-ID: <20090110021811.GJ1972@shareable.org> References: <4964EC55.4000507@codemonkey.ws> <20090107184103.GA19406@redhat.com> <496501CD.8060202@codemonkey.ws> <20090107194633.GB19406@redhat.com> <49665AE7.3000708@codemonkey.ws> <20090108212652.GB22504@redhat.com> <49667330.5070001@codemonkey.ws> <20090108224942.GA12848@shareable.org> <496688D9.1040708@redhat.com> <20090109104154.GA5164@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090109104154.GA5164@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: dlaor@redhat.com Daniel P. Berrange wrote: > On Fri, Jan 09, 2009 at 01:14:33AM +0200, Dor Laor wrote: > > Jamie Lokier wrote: > > >Anthony Liguori wrote: > > > > > >>Are we going to have a standard way of doing this in Linux distros such > > >>that these nics are treated differently from other nics? Have we gotten > > >>the appropriate distro folks to agree to this? > > >> > > > > > >That wouldn't work for older distros and Windows anyway. But you > > >might reasonably want to run apps doing guest-host communication on > > >older guest distros too, simply as an app, not requiring guest > > >customisation. > > > > > We can make fedora, rhel and libvirt support it. It might be a bit > > painful but since > > a network device was chosen for this propose then that's the right way > > to go. > > For new Fedora / RHEL yes, but a large number of people using virt are > doing so with old OS versions, and the chances of anyone retro-fitting > all old distros is near zero. You might get it done if they were back > porting the VirtIO NIC devices to old distros, but almost certainly not > for arbitrary NIC devices like rtl8139/e1000/etc because its a huge > QA testing headache to avoid regressions. In some circles, a major purpose of virtualisation is to run old OS versions, either copied from machines where the hardware is aging to keep a working system still working, or for compatibility testing. Changing a working guest setup isn't cool. Adding a small monitoring/reporting app (e.g. that shows the machine's load average, process table, network connections or whatever over a vmchannel) may be cool, provided it has negligable impact, even if changing its system configuration is not. -- Jamie