Re: [Qemu-devel] [patch 18/18] qemu: PCI device, disk and host network hot-add / hot-remove

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Feb 04, 2009 at 09:21:03AM -0600, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Wed, Feb 04, 2009 at 11:33:21AM -0200, Marcelo Tosatti wrote:
> >  
> >>Add monitor command to hot-add PCI devices (nic and storage).
> >>    
> >>Syntax is:
> >>    
> >>pci_add pcibus nic|storage params
> >>    
> >>It returns the bus slot and function for the newly added device on 
> >>success.
> >>    
> >>It is possible to attach a disk to a device after PCI initialization via
> >>the drive_add command. If so, a manual scan of the SCSI bus on the guest
> >>is necessary.
> >>    
> >>Save QEMUMachine necessary for drive_init.
> >>    
> >>Add monitor command to hot-remove devices, remove device data on _EJ0 
> >>notification.
> >>    
> >
> >Does this allow for hot-add of host TAP devices passing a open
> >file descriptor across with SCM_RIGHTS (man 7 unix) on the UNIX
> >domain socket connection to the monitor ?   This ability is
> >critical for libvirt, because we need to be able to allocate the
> >TAP devices ourselves & do various configuration tasks before giving
> >them to QEMU - the external script capability isn't suitable /flexible
> >enough for this.
> >  
> 
> It doesn't support this today but additional patches to enable that are 
> certainly welcome.  The best way would be a generic mechanism to send a 
> file descriptor to QEMU that could then be used anywhere fd= is valid.  
> For instance:
> 
> (qemu) receivefd unix:foo.sock,server
> fd=5
> (qemu) closefd 5

I think this is a bit of an unpleasent way to interact. There should be no
need for the user of the monitor to know or care about the FD number
from QEMU's side. When running the 'host_net_add' command QEMU should be
able to see that it is being asked to use an FD, and automatically receive
it at this time. This avoids need for user of the monitor to run separate
commands, and worry about closing the FD if something fails in the 2nd
command, and avoids having to parse the receivefd command, and splice 
that into the next command. eg I'd expect that

 (qemu)  host_net_add  tap,fd=,vlan=9,ifname=vnet3

should see the empty 'fd=' arg and just 'do the right thing' by using 
SCM_RIGHTS to fetch the FD.

Or could we avoid the FD passing, and just rely on giving an 'ifname'
that already exists, and expect QEMU to open this existing named TAP
device ? Though there may be difficulties with transfering "ownership"
of the TAP device, to ensure it disappears when QEMU quits, rather
than when the monitor caller quits.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|