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.
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.
Michal
--
Michal Novotny<minov...@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat
