Comment 13 for bug 1678322

After another breakdown of my usual testbed I went to ppc64el with an Emulex to continue tests.
Never should have trusted in x86 right :-)

# Prep simple guest
$ sudo apt install uvtool-libvirt
$ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=ppc64el label=daily release=zesty
$ cat template-ppc.xml
<domain type='kvm'>
  <os>
    <type arch="ppc64le" machine="pseries">hvm</type>
    <boot dev='hd' />
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <devices>
    <interface type='network'>
      <source network='default'/>
      <model type='virtio'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/3'/>
      <target port='0'/>
    </serial>
    <graphics type='vnc' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>
    <video/>
  </devices>
</domain>
$ ssh-keygen
$ sudo ppc64_cpu --smt=off
$ uvt-kvm create --password=ubuntu --template template-ppc.xml z-test release=zesty arch=ppc64el label=daily

# Prep VFs and attach
$ echo 4 | sudo tee /sys/bus/pci/devices/0005\:01\:00.0/sriov_numvfs

$ sudo modprobe vfio-pci
$ lspci -n -s 0005:01:01.3
0005:01:01.3 0200: 10df:e228 (rev 10)

$ cat VF-5.1.1.3.xml
<hostdev mode='subsystem' type='pci' managed='yes'>
  <source>
    <address domain='0x0005' bus='0x01' slot='0x01' function='0x3'/>
  </source>
</hostdev>
$ virsh attach-device z-test VF-5.1.1.3.xml

While the Emulex card I have struggles with being a proper VF, it is still enough (for now) to continue debug.
[ 864.164676] be2net 0005:01:01.3: MSIx enable failed
[ 864.164699] be2net 0005:01:01.3: Emulex OneConnect(Lancer) initialization failed
[ 864.164852] be2net: probe of 0005:01:01.3 failed with error -34

If you happen to know the Emulex issue, let me know.
Maybe just some special tweak on using those devices VFs on ppc?
Otherwise I'll keep it as-is until I understood why setrlimit is used instead of prlimit to change the target qemu attributes.