Re: [Qemu-devel] Re: [PATCH] Make NIC model fallback to default when specified model is not supported

[Michal Novotny]

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<address@hidden>, RHCE
Virtualization Team (xen userspace), Red Hat