Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

[Laine Stump <laine@redhat.com>]

On 6/12/19 7:59 AM, Jens Freimann wrote:
> On Wed, Jun 12, 2019 at 11:11:23AM +0200, Daniel P. Berrangé wrote:
>> On Tue, Jun 11, 2019 at 11:42:54AM -0400, Laine Stump wrote:
>>> On 5/17/19 8:58 AM, Jens Freimann wrote:
>> >
>>> > Command line example:
>>> >
>>> > qemu-system-x86_64 -enable-kvm -m 3072 -smp 3 \
>>> >          -machine q35,kernel-irqchip=split -cpu host   \
>>> >          -k fr   \
>>> >          -serial stdio   \
>>> >          -net none \
>>> >          -qmp unix:/tmp/qmp.socket,server,nowait \
>>> >          -monitor telnet:127.0.0.1:5555,server,nowait \
>>> >          -device 
>>> pcie-root-port,id=root0,multifunction=on,chassis=0,addr=0xa \
>>> >          -device pcie-root-port,id=root1,bus=pcie.0,chassis=1 \
>>> >          -device pcie-root-port,id=root2,bus=pcie.0,chassis=2 \
>>> >          -netdev 
>>> tap,script=/root/bin/bridge.sh,downscript=no,id=hostnet1,vhost=on \
>>> >          -device 
>>> virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:6f:55:cc,bus=root2,failover=on 
>>> \
>>> >          /root/rhel-guest-image-8.0-1781.x86_64.qcow2
>>> >
>>> > Then the primary device can be hotplugged via
>>> >   (qemu) device_add 
>>> vfio-pci,host=5e:00.2,id=hostdev0,bus=root1,standby=net1
>>>
>>>
>>> I guess this is the commandline on the migration destination, and as 
>>> far as
>>> I understand from this example, on the destination we (meaning 
>>> libvirt or
>>> higher level management application) must *not* include the assigned 
>>> device
>>> on the qemu commandline, but must instead hotplug the device later 
>>> after the
>>> guest CPUs have been restarted on the destination.
>>>
>>> So if I'm understanding correctly, the idea is that on the migration 
>>> source,
>>> the device may have been hotplugged, or may have been included when 
>>> qemu was
>>> originally started. Then qemu automatically handles the unplug of the 
>>> device
>>> on the source, but it seems qemu does nothing on the destination, 
>>> leaving
>>> that up to libvirt or a higher layer to implement.
>>>
>>> Then in order for this to work, libvirt (or OpenStack or oVirt or 
>>> whoever)
>>> needs to understand that the device in the libvirt config (it will 
>>> still be
>>> in the libvirt config, since from libvirt's POV it hasn't been 
>>> unplugged):
>>>
>>> 1) shouldn't be included in the qemu commandline on the destination,
>>
>> I don't believe that's the case.  The CLI args above are just 
>> illustrating
>> that it is now possible to *optionally* not specify the VFIO device on 
>> the
>> CLI. This is because previous versions of the patchset *always* required
>> the device on the CLI due to a circular dependancy in the CLI syntax. 
>> This
>> patch series version fixed that limitation, so now the VFIO device can be
>> cold plugged or hotplugged as desired.
> 
> I've mostly tested hotplugging but cold plugged should work as well.


Okay, in that case my issues 1, 3, and 4 are irrelevant (and (2) is 
handled by management), so the concerns from my previous email are all 
addressed.