Linux Virtualization - Jun 2018 - [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net

On Fri, 15 Jun 2018 05:34:24 +0300
"Michael S. Tsirkin" <mst at redhat.com> wrote:
> On Thu, Jun 14, 2018 at 12:02:31PM +0200, Cornelia Huck wrote:
> > > > I am not all that familiar with how Qemu manages network
devices. If we can
> > > > do all the
> > > > required management of the primary/standby devices within
Qemu, that is
> > > > definitely a better
> > > > approach without upper layer involvement.    
> > > 
> > > Right. I would imagine in the extreme case the upper layer
doesn't
> > > have to be involved at all if QEMU manages all hot plug/unplug
logic.
> > > The management tool can supply passthrough device and virtio with
the
> > > same group UUID, QEMU auto-manages the presence of the primary,
and
> > > hot plug the device as needed before or after the migration.  
> > 
> > I do not really see how you can manage that kind of stuff in QEMU
only.
> 
> So right now failover is limited to pci passthrough devices only.
> The idea is to realize the vfio device but not expose it
> to guest. Have a separate command to expose it to guest.
> Hotunplug would also hide it from guest but not unrealize it.
So, this would not be real hot(un)plug, but 'hide it from the guest',
right? The concept of "we have it realized in QEMU, but the guest can't
discover and use it" should be translatable to non-pci as well (at
least for ccw).
> 
> This will help ensure that e.g. on migration failure we can
> re-expose the device without risk of running out of resources.
Makes sense.

Should that 'hidden' state be visible/settable from outside as well
(e.g. via a property)? I guess yes, so that management software has a
chance to see whether a device is visible. Settable may be useful if we
find another use case for hiding realized devices.

On Fri, Jun 15, 2018 at 11:32:42AM +0200, Cornelia Huck
wrote:
> On Fri, 15 Jun 2018 05:34:24 +0300
> "Michael S. Tsirkin" <mst at redhat.com> wrote:
> 
> > On Thu, Jun 14, 2018 at 12:02:31PM +0200, Cornelia Huck wrote:
> 
> > > > > I am not all that familiar with how Qemu manages
network devices. If we can
> > > > > do all the
> > > > > required management of the primary/standby devices
within Qemu, that is
> > > > > definitely a better
> > > > > approach without upper layer involvement.    
> > > > 
> > > > Right. I would imagine in the extreme case the upper layer
doesn't
> > > > have to be involved at all if QEMU manages all hot
plug/unplug logic.
> > > > The management tool can supply passthrough device and virtio
with the
> > > > same group UUID, QEMU auto-manages the presence of the
primary, and
> > > > hot plug the device as needed before or after the migration.
> > > 
> > > I do not really see how you can manage that kind of stuff in QEMU
only.
> > 
> > So right now failover is limited to pci passthrough devices only.
> > The idea is to realize the vfio device but not expose it
> > to guest. Have a separate command to expose it to guest.
> > Hotunplug would also hide it from guest but not unrealize it.
> 
> So, this would not be real hot(un)plug, but 'hide it from the
guest',
> right? The concept of "we have it realized in QEMU, but the guest
can't
> discover and use it" should be translatable to non-pci as well (at
> least for ccw).
> 
> > 
> > This will help ensure that e.g. on migration failure we can
> > re-expose the device without risk of running out of resources.
> 
> Makes sense.
> 
> Should that 'hidden' state be visible/settable from outside as well
> (e.g. via a property)? I guess yes, so that management software has a
> chance to see whether a device is visible.
Might be handy for debug, but note that since QEMU manages this
state it's transient: can change at any time, so it's kind
of hard for management to rely on it.
> Settable may be useful if we
> find another use case for hiding realized devices.

On Fri, 15 Jun 2018 15:31:43 +0300
"Michael S. Tsirkin" <mst at redhat.com> wrote:
> On Fri, Jun 15, 2018 at 11:32:42AM +0200, Cornelia Huck wrote:
> > On Fri, 15 Jun 2018 05:34:24 +0300
> > "Michael S. Tsirkin" <mst at redhat.com> wrote:
> >   
> > > On Thu, Jun 14, 2018 at 12:02:31PM +0200, Cornelia Huck wrote:  
> >   
> > > > > > I am not all that familiar with how Qemu manages
network devices. If we can
> > > > > > do all the
> > > > > > required management of the primary/standby devices
within Qemu, that is
> > > > > > definitely a better
> > > > > > approach without upper layer involvement.      
> > > > > 
> > > > > Right. I would imagine in the extreme case the upper
layer doesn't
> > > > > have to be involved at all if QEMU manages all hot
plug/unplug logic.
> > > > > The management tool can supply passthrough device and
virtio with the
> > > > > same group UUID, QEMU auto-manages the presence of the
primary, and
> > > > > hot plug the device as needed before or after the
migration.
> > > > 
> > > > I do not really see how you can manage that kind of stuff in
QEMU only.
> > > 
> > > So right now failover is limited to pci passthrough devices only.
> > > The idea is to realize the vfio device but not expose it
> > > to guest. Have a separate command to expose it to guest.
> > > Hotunplug would also hide it from guest but not unrealize it.  
> > 
> > So, this would not be real hot(un)plug, but 'hide it from the
guest',
> > right? The concept of "we have it realized in QEMU, but the guest
can't
> > discover and use it" should be translatable to non-pci as well
(at
> > least for ccw).
> >   
> > > 
> > > This will help ensure that e.g. on migration failure we can
> > > re-expose the device without risk of running out of resources.  
> > 
> > Makes sense.
> > 
> > Should that 'hidden' state be visible/settable from outside as
well
> > (e.g. via a property)? I guess yes, so that management software has a
> > chance to see whether a device is visible.  
> 
> Might be handy for debug, but note that since QEMU manages this
> state it's transient: can change at any time, so it's kind
> of hard for management to rely on it.
Might be another reason to have this controlled by management software;
being able to find out easily why a device is not visible to the guest
seems to be a useful thing.

Anyway, let's defer this discussion until it is clear how we actually
want to handle the whole setup.
> 
> > Settable may be useful if we
> > find another use case for hiding realized devices.