From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44566 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OxeKP-0005Fk-SE for qemu-devel@nongnu.org; Mon, 20 Sep 2010 07:14:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OxeKO-0006Qc-OJ for qemu-devel@nongnu.org; Mon, 20 Sep 2010 07:14:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9846) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OxeKO-0006QQ-HC for qemu-devel@nongnu.org; Mon, 20 Sep 2010 07:14:32 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o8KBEUmS031242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Sep 2010 07:14:31 -0400 Message-ID: <4C974240.4070208@redhat.com> Date: Mon, 20 Sep 2010 13:15:12 +0200 From: Michal Novotny MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Make NIC model fallback to default when specified model is not supported References: <4C972DCF.1050003@redhat.com> <4C9738B4.4010809@redhat.com> <4C973C12.7050905@redhat.com> <20100920105341.GD18143@redhat.com> <4C973FFD.9080904@redhat.com> <20100920110754.GE18143@redhat.com> In-Reply-To: <20100920110754.GE18143@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Paolo Bonzini , qemu-devel On 09/20/2010 01:07 PM, Daniel P. Berrange wrote: > On Mon, Sep 20, 2010 at 01:05:33PM +0200, Michal Novotny wrote: > >> On 09/20/2010 12:53 PM, Daniel P. Berrange wrote: >> >>> On Mon, Sep 20, 2010 at 12:48:50PM +0200, Michal Novotny wrote: >>> >>> >>>> On 09/20/2010 12:34 PM, Paolo Bonzini wrote: >>>> >>>> >>>>> On 09/20/2010 11:47 AM, Michal Novotny wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> this is the patch to introduce a NIC model fallback to default when >>>>>> model >>>>>> specified is not supported. It's been tested on i386-softmmu target on >>>>>> i386 host using the Windows XP x86 virtual machine and by trying to >>>>>> setup >>>>>> the invalid (unsupported) model of NIC device. Also, the new constant in >>>>>> the net.h called the DEFAULT_NIC_MODEL has been introduced to be able to >>>>>> change the default NIC model easily. This variable is being used to set >>>>>> the default NIC model when necessary. >>>>>> >>>>>> >>>>> Why? If it's not supported, it shouldn't run. >>>>> >>>>> Paolo >>>>> >>>>> >>>> I don't think so. It makes sense it shouldn't run for case of pure qemu >>>> but since there's newly added support for xen (and also there's support >>>> for other virtualization platforms to be used with the qemu device >>>> model) it should fallback with just a warning since otherwise those >>>> platforms, like e.g. mentioned Xen, will leave defunct device models >>>> there and the guests won't run be running at all ending up with no >>>> state. If there's a warning with information it's falling back to >>>> default the user can notice if he wants to but it won't leave the >>>> defunct device models anymore which can be pretty hard to determine >>>> what's going on there for standard user that doesn't have much >>>> experience with e.g. Xen yet. >>>> >>>> >>> IMHO this is just a bug in the xen mgmt layer. If the QEMU device model >>> dies/quits, then XenD should teardown the guest, since you can't do any >>> useful work once the device model has crashed. Silently switching to a >>> different NIC model than the one requested is definitely a wrong approach. >>> >>> Daniel >>> >>> >> When the qemu-dm has crashed we can't do anything with the guest, that's >> correct. Nevertheless do you think that we should bail with error and >> just fix the layer of xen management to check whether there's a device >> model still running or not? It's being spawned by XenD itself so we >> would need to check whether this process is not a zombie using the >> /proc/$PID/stat or use some better way to get the state. Unfortunately >> using /proc/$PID/stat would kill the portability of the code. >> >> The other way is to implement the thread that will be (periodically or >> "on change") checking the device model state and that will be >> terminating the domain when device model dies/quits. I'm not saying this >> is the bad approach but we've been talking with Mirek about at least >> RHEL-5 version and he told me that he recommends to implement a fallback >> to the default NIC. >> > If XenD holds open a connection to the QEMU monitor socket, then it > can easily receive a POLLHUP when QEMU dies. This is the approach > most mgmt tools use for detecting QEMU death. > I don't know how this is being implemented in the new qemu code that's implementing Xen support but from what I saw the upstream Xen-4.1 is not using it yet so implementing this into the new xen management layer could be a good idea for somebody working on the xen layer for qemu because I'm not familiar with this yet. > >> Daniel, if you consider RHEL-5 version, what do you prefer to do with >> this one? Fix it somehow in the XenD or is altering the device model OK >> for this version? Also, the patch has been already sent upstream Xen for >> consideration about an hour ago. >> > RHEL5 Xen maintenance isn't a concern of qemu-devel really, so this > is not the place to decide that. > > Daniel > Well, this way I guess we should have 2, maybe 3 different approaches - different for qemu itself and for upstream version Xen using the older version of qemu-dm and RHEL-5 version. Therefore I think we should drop the patch for qemu (the one sent to this list) and decide about the others using their own lists/discussions. Michal -- Michal Novotny, RHCE Virtualization Team (xen userspace), Red Hat