|
From: | Michal Novotny |
Subject: | Re: [Qemu-devel] Re: [PATCH] Make NIC model fallback to default when specified model is not supported |
Date: | Mon, 20 Sep 2010 13:15:12 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4 |
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. PaoloI 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. DanielWhen 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.
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.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
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<address@hidden>, RHCE Virtualization Team (xen userspace), Red Hat
[Prev in Thread] | Current Thread | [Next in Thread] |