1. 08 4月, 2020 1 次提交
  2. 06 4月, 2020 1 次提交
  3. 03 4月, 2020 1 次提交
  4. 30 3月, 2020 1 次提交
  5. 27 3月, 2020 1 次提交
  6. 26 3月, 2020 1 次提交
  7. 24 3月, 2020 1 次提交
  8. 16 3月, 2020 3 次提交
  9. 04 3月, 2020 3 次提交
  10. 21 2月, 2020 3 次提交
  11. 14 2月, 2020 2 次提交
  12. 06 2月, 2020 1 次提交
  13. 30 1月, 2020 1 次提交
    • L
      conf: parse/format <teaming> subelement of <interface> · fb0509d0
      Laine Stump 提交于
      The subelement <teaming> of <interface> devices is used to configure a
      simple teaming association between two interfaces in a domain. Example:
      
        <interface type='bridge'>
          <source bridge='br0'/>
          <model type='virtio'/>
          <mac address='00:11:22:33:44:55'/>
          <alias name='ua-backup0'/>
          <teaming type='persistent'/>
        </interface>
        <interface type='hostdev'>
          <source>
            <address type='pci' bus='0x02' slot='0x10' function='0x4'/>
          </source>
          <mac address='00:11:22:33:44:55'/>
          <teaming type='transient' persistent='ua-backup0'/>
        </interface>
      
      The interface with <teaming type='persistent'/> is assumed to always
      be present, while the interface with type='transient' may be be
      unplugged and later re-plugged; the persistent='blah' attribute (and
      in the one currently available implementation, also the matching MAC
      addresses) is what associates the two devices with each other. It is
      up to the hypervisor and the guest network drivers to determine what
      to do with this information.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      fb0509d0
  14. 25 1月, 2020 1 次提交
  15. 24 1月, 2020 1 次提交
  16. 16 1月, 2020 2 次提交
  17. 09 1月, 2020 1 次提交
  18. 06 1月, 2020 1 次提交
  19. 25 12月, 2019 1 次提交
  20. 21 12月, 2019 1 次提交
  21. 20 12月, 2019 1 次提交
  22. 19 12月, 2019 1 次提交
    • D
      Introducing new address type='unassigned' for PCI hostdevs · 96999404
      Daniel Henrique Barboza 提交于
      This patch introduces a new PCI hostdev address type called
      'unassigned'. This new type gives users the option to add
      PCI hostdevs to the domain XML in an 'unassigned' state, meaning
      that the device exists in the domain, is managed by Libvirt
      like any regular PCI hostdev, but the guest does not have
      access to it.
      
      This adds extra options for managing PCI device binding
      inside Libvirt, for example, making all the managed PCI hostdevs
      declared in the domain XML to be detached from the host and bind
      to the chosen driver and, at the same time, allowing just a
      subset of these devices to be usable by the guest.
      
      Next patch will use this new address type in the QEMU driver to
      avoid adding unassigned devices to the QEMU launch command line.
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      96999404
  23. 17 12月, 2019 1 次提交
    • M
      schemas: Introduce disk type NVMe · e1b02289
      Michal Privoznik 提交于
      There is this class of PCI devices that act like disks: NVMe.
      Therefore, they are both PCI devices and disks. While we already
      have <hostdev/> (and can assign a NVMe device to a domain
      successfully) we don't have disk representation. There are three
      problems with PCI assignment in case of a NVMe device:
      
      1) domains with <hostdev/> can't be migrated
      
      2) NVMe device is assigned whole, there's no way to assign only a
         namespace
      
      3) Because hypervisors see <hostdev/> they don't put block layer
         on top of it - users don't get all the fancy features like
         snapshots
      
      NVMe namespaces are way of splitting one continuous NVDIMM memory
      into smaller ones, effectively creating smaller NVMe-s (which can
      then be partitioned, LVMed, etc.)
      
      Because of all of this the following XML was chosen to model a
      NVMe device:
      
        <disk type='nvme' device='disk'>
          <driver name='qemu' type='raw'/>
          <source type='pci' managed='yes' namespace='1'>
            <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
          </source>
          <target dev='vda' bus='virtio'/>
        </disk>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      e1b02289
  24. 13 12月, 2019 2 次提交
    • H
      conf: create memory bandwidth monitor. · 40a070ae
      Huaqiang 提交于
      Following domain configuration changes create two memory bandwidth
      monitors: one is monitoring the bandwidth consumed by vCPU 0,
      another is for vCPU 5.
      
      ```
                     <cputune>
                       <memorytune vcpus='0-4'>
                         <node id='0' bandwidth='20'/>
                         <node id='1' bandwidth='30'/>
             +           <monitor vcpus='0'/>
                       </memorytune>
             +         <memorytune vcpus='5'>
             +           <monitor vcpus='5'/>
             +         </memorytune>
      
                     </cputune>
          ```
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      Signed-off-by: NHuaqiang <huaqiang.wang@intel.com>
      40a070ae
    • H
      cachetune schema: a looser check for the order of <cache> and <monitor> element · 1d0c3c3a
      Huaqiang 提交于
      Originally, inside <cputune/cachetune>, it requires the <cache> element to
      be in the position before <monitor>, and following configuration is not
      permitted by schema, but it is better to let it be valid.
      
        <cputune>
          <cachetune vcpus='0-1'>
            <monitor level='3' vcpus='0-1'/>
                  ^
                  |__ Not permitted originally because it is in the place
                      before <cache> element.
      
            <cache id='0' level='3' type='both' size='3' unit='MiB'/>
            <cache id='1' level='3' type='both' size='3' unit='MiB'/>
          </cachetune>
          ...
        </cputune>
      
      And, let schema do more strict check by identifying following configuration to
      be invalid, due to <cachetune> should contain at least one <cache> or <monitor>
      element.
      
        <cputune>
          <cachetune vcpus='0-1'>
              ^
              |__ a <cachetune> SHOULD contain at least one <cache> or <monitor>
      
          </cachetune>
          ...
        </cputune>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      Signed-off-by: NHuaqiang <huaqiang.wang@intel.com>
      1d0c3c3a
  25. 10 12月, 2019 2 次提交
    • P
      conf: domaincaps: Add 'backup' feature flag · 528191c7
      Peter Krempa 提交于
      This flag will allow figuring out whether the hypervisor supports the
      incremental backup and checkpoint features.
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      528191c7
    • E
      backup: Document new XML for backups · 252958ee
      Eric Blake 提交于
      Prepare for new backup APIs by describing the XML that will represent
      a backup.  The XML resembles snapshots and checkpoints in being able
      to select actions for a set of disks, but has other differences.  It
      can support both push model (the hypervisor does the backup directly
      into the destination file) and pull model (the hypervisor exposes an
      access port for a third party to grab what is necessary).  Add
      testsuite coverage for some minimal uses of the XML.
      
      The <disk> element within <domainbackup> tries to model the same
      elements as a <disk> under <domain>, but sharing the RNG grammar
      proved to be hairy. That is in part because while <domain> use
      <source> to describe a host resource in use by the guest, a backup job
      is using a host resource that is not visible to the guest: a push
      backup action is instead describing a <target> (which ultimately could
      be a remote network resource, but for simplicity the RNG just
      validates a local file for now), and a pull backup action is instead
      describing a temporary local file <scratch> (which probably should not
      be a remote resource).  A future refactoring may thus introduce some
      way to parameterize RNG to accept <disk type='FOO'>...</disk> so that
      the name of the subelement can be <source> for domain, or <target> or
      <scratch> as needed for backups. Future patches may improve this area
      of code.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      252958ee
  26. 04 12月, 2019 2 次提交
  27. 22 11月, 2019 1 次提交
  28. 15 11月, 2019 1 次提交
  29. 13 11月, 2019 1 次提交