1. 04 10月, 2017 1 次提交
    • L
      qemu: Support multiqueue virtio-blk · abca72fa
      Lin Ma 提交于
      qemu 2.7.0 introduces multiqueue virtio-blk(commit 2f27059).
      This patch introduces a new attribute "queues". An example of
      the XML:
      
      <disk type='file' device='disk'>
        <driver name='qemu' type='qcow2' queues='4'/>
      
      The corresponding QEMU command line:
      
      -device virtio-blk-pci,scsi=off,num-queues=4,id=virtio-disk0
      Signed-off-by: NLin Ma <lma@suse.com>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      abca72fa
  2. 03 10月, 2017 1 次提交
  3. 28 9月, 2017 2 次提交
    • A
      util: Add TLS attributes to virStorageSource · f1705485
      Ashish Mittal 提交于
      Add an optional virTristateBool haveTLS to virStorageSource to
      manage whether a storage source will be using TLS.
      
      Sample XML for a VxHS disk:
      
      <disk type='network' device='disk'>
        <driver name='qemu' type='raw' cache='none'/>
        <source protocol='vxhs' name='eb90327c-8302-4725-9e1b-4e85ed4dc251' tls='yes'>
          <host name='192.168.0.1' port='9999'/>
        </source>
        <target dev='vda' bus='virtio'/>
      </disk>
      
      Additionally add a tlsFromConfig boolean to control whether the TLS
      setting was due to domain configuration or qemu.conf global setting
      in order to decide whether to Format the haveTLS setting for either
      a live or saved domain configuration file.
      
      Update the qemuxml2xmltest in order to add a test to show the proper
      parsing.
      
      Also update the docs to describe the tls attribute.
      Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      f1705485
    • J
      docs: Clean up the description for network disk protocol options · 70ad3052
      John Ferlan 提交于
      Clean up the description a bit to make it more readable and not
      appear as one long run-on paragraph.
      70ad3052
  4. 27 9月, 2017 2 次提交
  5. 20 9月, 2017 2 次提交
  6. 18 9月, 2017 1 次提交
  7. 15 9月, 2017 1 次提交
    • J
      docs: Remove unnecessary <auth> example for iscsi disk type='volume' · 4775ca27
      John Ferlan 提交于
      Alter the example to remove the <auth> from:
      
        <disk type='volume' device='disk'>
          <driver name='qemu' type='raw'/>
          <source pool='iscsi-pool' volume='unit:0:0:1' mode='host'/>
          <auth username='myuser'>
            <secret type='iscsi' usage='libvirtiscsi'/>
          </auth>
          <target dev='vdb' bus='virtio'/>
        </disk>
      
      and
      
        <disk type='volume' device='disk'>
          <driver name='qemu' type='raw'/>
          <source pool='iscsi-pool' volume='unit:0:0:2' mode='direct'/>
          <auth username='myuser'>
            <secret type='iscsi' usage='libvirtiscsi'/>
          </auth>
          <target dev='vdc' bus='virtio'/>
        </disk>
      
      The reality is, it's not even used. For a <source pool> the authdef
      from the storage source pool will supercede whatever is in the <disk>
      definition during virStorageTranslateDiskSourcePool processing. In fact,
      if the pool doesn't have/need authentication, then the authdef would
      be removed anyway as the storage pool would be handling things.
      
      The "proof" for this is in the adjustment to the test to add an
      <auth> for a disk. The resulting .args file won't add what normally
      would be added "myname:encodedpassword@" prior to the hostname in
      the IQN (e.g. iscsi://myname:encodedpassword@iscsi.example.org:3260/...
      4775ca27
  8. 30 8月, 2017 1 次提交
  9. 29 8月, 2017 1 次提交
  10. 08 8月, 2017 1 次提交
  11. 03 8月, 2017 3 次提交
  12. 02 8月, 2017 1 次提交
  13. 26 7月, 2017 1 次提交
  14. 21 7月, 2017 1 次提交
    • S
      qemu: Enable NUMA node tag in pci-root for PPC64 · e5a05799
      Shivaprasad G Bhat 提交于
      This patch addresses the same aspects on PPC the bug 1103314 addressed
      on x86.
      
      PCI expander bus creates multiple primary PCI busses, where each of these
      busses can be assigned a specific NUMA affinity, which, on x86 is
      advertised through ACPI on a per-bus basis.
      
      For SPAPR, a PHB's NUMA affinities are assigned on a per-PHB basis, and
      there is no mechanism for advertising NUMA affinities to a guest on a
      per-bus basis. So, even if qemu-ppc manages to get some sort of multi-bus
      topology working using PXB, there is no way to expose the affinities
      of these busses to the guest. It can only be exposed on a per-PHB/per-domain
      basis.
      
      So patch enables NUMA node tag in pci-root controller on PPC.
      
      The way to set the NUMA node is through the numa_node option of
      spapr-pci-host-bridge device. However for the implicit PHB, the only way
      to set the numa_node is from the -global option. The -global option applies
      to all the PHBs unless explicitly specified with the option on the
      respective PHB of CLI. The default PHB has the emulated devices only, so
      the patch prevents setting the NUMA node for the default PHB.
      Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      e5a05799
  15. 16 7月, 2017 1 次提交
  16. 15 7月, 2017 1 次提交
  17. 11 7月, 2017 3 次提交
  18. 27 6月, 2017 1 次提交
  19. 20 6月, 2017 1 次提交
  20. 08 6月, 2017 9 次提交
  21. 26 5月, 2017 1 次提交
  22. 15 5月, 2017 3 次提交
  23. 28 4月, 2017 1 次提交
    • L
      conf: don't ignore <target dev='blah'/> for macvtap interfaces · 9cb89114
      Laine Stump 提交于
      The parser had been clearing out *all* suggested device names for
      type='direct' (aka macvtap) interfaces. All of the code implementing
      macvtap allows for a user-specified device name, so we should allow
      it. In the case that an interface name starts with "macvtap" or
      "macvlan" though, we do still clear it out, just as we do with "vnet"
      (which is the prefix used for automatically generated tap device
      names), since those are the prefixes for the names we autogenerate for
      macvtap and macvlan devices.
      
      Resolves: https://bugzilla.redhat.com/1335798
      9cb89114