1. 19 10月, 2017 11 次提交
  2. 05 10月, 2017 3 次提交
  3. 28 9月, 2017 1 次提交
    • A
      qemu: Add TLS support for Veritas HyperScale (VxHS) · 6885b51e
      Ashish Mittal 提交于
      Alter qemu command line generation in order to possibly add TLS for
      a suitably configured domain.
      
      Sample TLS args generated by libvirt -
      
          -object tls-creds-x509,id=objvirtio-disk0_tls0,dir=/etc/pki/qemu,\
          endpoint=client,verify-peer=yes \
          -drive file.driver=vxhs,file.tls-creds=objvirtio-disk0_tls0,\
          file.vdisk-id=eb90327c-8302-4725-9e1b-4e85ed4dc251,\
          file.server.type=tcp,file.server.host=192.168.0.1,\
          file.server.port=9999,format=raw,if=none,\
          id=drive-virtio-disk0,cache=none \
          -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,\
          id=virtio-disk0
      
      Update the qemuxml2argvtest with a couple of examples. One for a
      simple case and the other a bit more complex where multiple VxHS disks
      are added where at least one uses a VxHS that doesn't require TLS
      credentials and thus sets the domain disk source attribute "tls = 'no'".
      
      Update the hotplug to be able to handle processing the tlsAlias whether
      it's to add the TLS object when hotplugging a disk or to remove the TLS
      object when hot unplugging a disk.  The hot plug/unplug code is largely
      generic, but the addition code does make the VXHS specific checks only
      because it needs to grab the correct config directory and generate the
      object as the command line would do.
      Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      6885b51e
  4. 27 9月, 2017 1 次提交
  5. 22 9月, 2017 1 次提交
  6. 15 9月, 2017 2 次提交
  7. 05 9月, 2017 1 次提交
  8. 01 9月, 2017 1 次提交
  9. 20 7月, 2017 1 次提交
  10. 18 7月, 2017 1 次提交
  11. 15 7月, 2017 2 次提交
  12. 28 6月, 2017 2 次提交
  13. 21 6月, 2017 1 次提交
  14. 20 6月, 2017 1 次提交
  15. 16 6月, 2017 1 次提交
  16. 13 6月, 2017 2 次提交
  17. 12 6月, 2017 1 次提交
  18. 08 6月, 2017 2 次提交
  19. 07 6月, 2017 1 次提交
  20. 23 5月, 2017 1 次提交
    • L
      Revert "qemu: propagate bridge MTU into qemu "host_mtu" option" · 77780a29
      Laine Stump 提交于
      This reverts commit 2841e675.
      
      It turns out that adding the host_mtu field to the PCI capabilities in
      the guest bumps the length of PCI capabilities beyond the 32 byte
      boundary, so the virtio-net device gets 64 bytes of ioport space
      instead of 32, which offsets the address of all the other following
      devices. Migration doesn't work very well when the location and length
      of PCI capabilities of devices is changed between source and
      destination.
      
      This means that we need to make sure that the absence/presence of
      host_mtu on the qemu commandline always matches between source and
      destination, which means that we need to make setting of host_mtu an
      opt-in thing (it can't happen automatically when the bridge being used
      has a non-default MTU, which is what commit 2841e675 implemented).
      
      I do want to re-implement this feature with an <mtu auto='on'/>
      setting, but probably won't backport that to any stable branches, so
      I'm first reverting the original commit, and that revert can be pushed
      to the few releases that have been made since the original (3.1.0 -
      3.3.0)
      
      Resolves: https://bugzilla.redhat.com/1449346
      77780a29
  21. 22 5月, 2017 2 次提交
  22. 11 5月, 2017 1 次提交