1. 09 2月, 2017 1 次提交
    • J
      conf: Add new xml elements for file memorybacking support · bc6d3121
      Jaroslav Safka 提交于
      This part introduces new xml elements for file based
      memorybacking support and their parsing.
      (It allows vhost-user to be used without hugepages.)
      
      New xml elements:
      <memoryBacking>
        <source type="file|anonymous"/>
        <access mode="shared|private"/>
        <allocation mode="immediate|ondemand"/>
      </memoryBacking>
      bc6d3121
  2. 08 2月, 2017 1 次提交
  3. 26 1月, 2017 2 次提交
  4. 18 1月, 2017 1 次提交
  5. 17 1月, 2017 1 次提交
  6. 10 1月, 2017 1 次提交
  7. 07 1月, 2017 2 次提交
    • J
      conf: Add more fchost search fields for storage pool vHBA creation · bb74a7ff
      John Ferlan 提交于
      Add new fields to the fchost structure to allow creation of a vHBA via
      the storage pool when a parent_wwnn/parent_wwpn or parent_fabric_wwn is
      supplied in the storage pool XML.
      bb74a7ff
    • J
      nodedev: Add the ability to create vHBA by parent wwnn/wwpn or fabric_wwn · 2b13361b
      John Ferlan 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1349696
      
      When creating a vHBA, the process is to feed XML to nodeDeviceCreateXML
      that lists the <parent> scsi_hostX to use to create the vHBA. However,
      between reboots, it's possible that the <parent> changes its scsi_hostX
      to scsi_hostY and saved XML to perform the creation will either fail or
      create a vHBA using the wrong parent.
      
      So add the ability to provide "wwnn" and "wwpn" or "fabric_wwn" to
      the <parent> instead of a name of the scsi_hostN that is the parent.
      The allowed XML will thus be:
      
        <parent>scsi_host3</parent>  (current)
      
      or
      
        <parent wwnn='$WWNN' wwpn='$WWPN'/>
      
      or
      
        <parent fabric_wwn='$WWNN'/>
      
      Using the wwnn/wwpn or fabric_wwn ensures the same 'scsi_hostN' is
      selected between hardware reconfigs or host reboots. The fabric_wwn
      Using the wwnn/wwpn pair will provide the most specific search option,
      while fabric_wwn will at least ensure usage of the same SAN, but maybe
      not the same scsi_hostN.
      
      This patch will add the new fields to the nodedev.rng for input purposes
      only since the input XML is essentially thrown away, no need to Format
      the values since they'd already be printed as part of the scsi_host
      data block.
      
      New API virNodeDeviceGetParentHostByWWNs will take the parent "wwnn" and
      "wwpn" in order to search the list of devices for matching capability
      data fields wwnn and wwpn.
      
      New API virNodeDeviceGetParentHostByFabricWWN will take the parent "fabric_wwn"
      in order to search the list of devices for matching capability data field
      fabric_wwn.
      2b13361b
  8. 19 12月, 2016 1 次提交
  9. 16 12月, 2016 4 次提交
  10. 14 12月, 2016 2 次提交
  11. 13 12月, 2016 1 次提交
  12. 07 12月, 2016 1 次提交
  13. 06 12月, 2016 1 次提交
  14. 25 11月, 2016 1 次提交
    • E
      conf: Wire up the vhost-scsi connection from/to XML · ae5d30a0
      Eric Farman 提交于
      With the QEMU components in place, provide the XML parsing to
      invoke that code when given the following XML snippet:
      
          <hostdev mode='subsystem' type='scsi_host'>
            <source protocol='vhost' wwpn='naa.501234567890abcd'/>
          </hostdev>
      
      An optional address element can be specified within the hostdev
      (pick CCW or PCI as necessary):
      
          <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0625'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
      
      Add basic vhost-scsi tests which were cloned from hostdev-scsi-virtio-scsi
      in both xml2argv and xml2xml. Added ones for both vhost-scsi-ccw and
      vhost-scsi-pci since the syntaxes are slightly different between them.
      
      Also adjusted the docs to describe the changes.
      Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
      Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
      ae5d30a0
  15. 02 11月, 2016 2 次提交
  16. 26 10月, 2016 1 次提交
  17. 24 10月, 2016 1 次提交
    • P
      domain: Add optional 'tls' attribute for TCP chardev · 0298531b
      Pavel Hrdina 提交于
      Add an optional "tls='yes|no'" attribute for a TCP chardev.
      
      For QEMU, this will allow for disabling the host config setting of the
      'chardev_tls' for a domain chardev channel by setting the value to "no" or
      to attempt to use a host TLS environment when setting the value to "yes"
      when the host config 'chardev_tls' setting is disabled, but a TLS environment
      is configured via either the host config 'chardev_tls_x509_cert_dir' or
      'default_tls_x509_cert_dir'
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      0298531b
  18. 14 10月, 2016 2 次提交
  19. 28 9月, 2016 1 次提交
  20. 22 9月, 2016 4 次提交
    • J
      Show host model in domain capabilities · 14319c81
      Jiri Denemark 提交于
      The domain capabilities XML is capable of showing whether each guest CPU
      mode is supported or not with a possibility to provide additional
      details. This patch enhances host-model capability to advertise the
      exact CPU model which will be used as a host-model:
      
          <cpu>
              ...
              <mode name='host-model' supported='yes'>
                  <model fallback='allow'>Broadwell</model>
                  <vendor>Intel</vendor>
                  <feature policy='disable' name='aes'/>
                  <feature policy='require' name='vmx'/>
              </mode>
              ...
          </cpu>
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      14319c81
    • J
      85105b0a
    • J
      domcaps: Add CPU usable flag · d4c007e6
      Jiri Denemark 提交于
      In case a hypervisor is able to tell us a list of supported CPU models
      and whether each CPU models can be used on the current host, we can
      propagate this to domain capabilities. This is a better alternative
      to calling virConnectCompareCPU for each supported CPU model.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      d4c007e6
    • J
      domcaps: Add support for listing supported CPU models · 167280e7
      Jiri Denemark 提交于
      The patch adds <cpu> element to domain capabilities XML:
      
          <cpu>
              <mode name='host-passthrough' supported='yes'/>
              <mode name='host-model' supported='yes'/>
              <mode name='custom' supported='yes'>
                  <model>Broadwell</model>
                  <model>Broadwell-noTSX</model>
                  ...
              </mode>
          </cpu>
      
      Applications can use it to inspect what CPU configuration modes are
      supported for a specific combination of domain type, emulator binary,
      guest architecture and machine type.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      167280e7
  21. 16 9月, 2016 1 次提交
  22. 09 9月, 2016 2 次提交
  23. 03 9月, 2016 1 次提交
  24. 25 8月, 2016 1 次提交
    • P
      conf: Add XML for individual vCPU hotplug · 5847bc5c
      Peter Krempa 提交于
      Individual vCPU hotplug requires us to track the state of any vCPU. To
      allow this add the following XML:
      
      <domain>
        ...
        <vcpu current='2'>3</vcpu>
        <vcpus>
          <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/>
          <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/>
          <vcpu id='1' enabled='no' hotpluggable='yes'/>
        </vcpus>
        ...
      
      The 'enabled' attribute allows to control the state of the vcpu.
      'hotpluggable' controls whether given vcpu can be hotplugged and 'order'
      allows to specify the order to add the vcpus.
      5847bc5c
  25. 20 8月, 2016 3 次提交
    • L
      network: allow limiting a <forwarder> element to certain domains · 0b6336c2
      Laine Stump 提交于
      For some unknown reason the original implementation of the <forwarder>
      element only took advantage of part of the functionality in the
      dnsmasq feature it exposes - it allowed specifying the ip address of a
      DNS server which *all* DNS requests would be forwarded to, like this:
      
         <forwarder addr='192.168.123.25'/>
      
      This is a frontend for dnsmasq's "server" option, which also allows
      you to specify a domain that must be matched in order for a request to
      be forwarded to a particular server. This patch adds support for
      specifying the domain. For example:
      
         <forwarder domain='example.com' addr='192.168.1.1'/>
         <forwarder domain='www.example.com'/>
         <forwarder domain='travesty.org' addr='10.0.0.1'/>
      
      would forward requests for bob.example.com, ftp.example.com and
      joe.corp.example.com all to the DNS server at 192.168.1.1, but would
      forward requests for travesty.org and www.travesty.org to
      10.0.0.1. And due to the second line, requests for www.example.com,
      and odd.www.example.com would be resolved by the libvirt network's own
      DNS server (i.e. thery wouldn't be immediately forwarded) even though
      they also match 'example.com' - the match is given to the entry with
      the longest matching domain. DNS requests not matching any of the
      entries would be resolved by the libvirt network's own DNS server.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1331796
      0b6336c2
    • L
      network: allow disabling dnsmasq's DNS server · 9065cfaa
      Laine Stump 提交于
      If you define a libvirt virtual network with one or more IP addresses,
      it starts up an instance of dnsmasq. It's always been possible to
      avoid dnsmasq's dhcp server (simply don't include a <dhcp> element),
      but until now it wasn't possible to avoid having the DNS server
      listening; even if the network has no <dns> element, it is started
      using default settings.
      
      This patch adds a new attribute to <dns>: enable='yes|no'. For
      backward compatibility, it defaults to 'yes', but if you don't want a
      DNS server created for the network, you can simply add:
      
         <dns enable='no'/>
      
      to the network configuration, and next time the network is started
      there will be no dns server created (if there is dhcp configuration,
      dnsmasq will be started with "port=0" which disables the DNS server;
      if there is no dhcp configuration, dnsmasq won't be started at all).
      9065cfaa
    • L
      network: new network forward mode 'open' · 25e8112d
      Laine Stump 提交于
      The new forward mode 'open' is just like mode='route', except that no
      firewall rules are added to assure that any traffic does or doesn't
      pass. It is assumed that either they aren't necessary, or they will be
      setup outside the scope of libvirt.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=846810
      25e8112d
  26. 12 8月, 2016 1 次提交
    • M
      schema: Don't validate paths · c4b92f1a
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1353296
      
      On UNIX like systems there are no constraints on what characters
      can be in file/dir names (except for NULL, obviously). Moreover,
      some values that we think of as paths (e.g. disk source) are not
      necessarily paths at all. For instance, some hypervisors take
      that as an arbitrary identifier and corresponding file is then
      looked up by hypervisor in its table. Instead of trying to fix
      our regular expressions (and forgetting to include yet another
      character there), lets drop the validation completely.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      c4b92f1a