On Wed, Apr 06, 2016 at 11:52:56PM +0000, Ilya Maximets wrote: > ------- Original Message ------- > Sender : Michael S. Tsirkin<m...@redhat.com> > Date : Apr 05, 2016 13:46 (GMT+03:00) > Title : Re: [PATCH 0/4] Fix QEMU crash on vhost-user socket disconnect. > > > On Thu, Mar 31, 2016 at 09:02:01AM +0300, Ilya Maximets wrote: > > > On 30.03.2016 20:01, Michael S. Tsirkin wrote: > > > > On Wed, Mar 30, 2016 at 06:14:05PM +0300, Ilya Maximets wrote: > > > >> Currently QEMU always crashes in following scenario (assume that > > > >> vhost-user application is Open vSwitch with 'dpdkvhostuser' port): > > > > > > > > In fact, wouldn't the right thing to do be stopping the VM? > > > > > > I don't think that is reasonable to stop VM on failure of just one of > > > network interfaces. > > > > We don't start QEMU until vhost user connects, either. > > Making guest run properly with a backend is a much bigger > > project, let's tackle this separately. > > > > Also, I think handling graceful disconnect is the correct first step. > > Handling misbehaving clients is much harder as we have asserts on remote > > obeying protocol rules all over the place. > > > > > There may be still working vhost-kernel interfaces. > > > Even connection can still be established if vhost-user interface was in > > > bonding with kernel interface. > > > > Could not parse this. > > > > > Anyway user should be able to save all his data before QEMU restart. > > > > So reconnect a new backend, and VM will keep going. > > We cant't do this because of 2 reasons: > 1. Segmentation fault of QEMU on disconnect. (fixed by this patch-set) > 2. There is no reconnect functionality in current QEMU version. > > So, what are you talking about? > > Best regards, Ilya Maximets.
One can currently disconnect vhost user clients without killing guests using migration: - save vm - quit qemu - start new qemu - load vm Or using hotplug - request unplug - wait for guest eject - create new device I would like to make sure we do not create an expectation that guests keep going unconditionally with device present even with backend disconnected. Unfortunately your patchset might create such expectation. -- MST
