1. 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
  2. 27 1月, 2020 1 次提交
  3. 25 1月, 2020 1 次提交
  4. 13 1月, 2020 2 次提交
  5. 03 1月, 2020 1 次提交
  6. 19 12月, 2019 4 次提交
  7. 17 12月, 2019 15 次提交
  8. 10 12月, 2019 1 次提交
  9. 09 12月, 2019 3 次提交
  10. 25 11月, 2019 2 次提交
  11. 21 11月, 2019 4 次提交
  12. 15 11月, 2019 3 次提交
    • M
      tests: Mock access to /dev/kvm · 9e4445eb
      Michal Privoznik 提交于
      Some of our tests try to validate domain XMLs they are working
      with (not intentionally, simply because they call top level
      domain XML parse function). Anyway, this implies that we build
      domain capabilities also - see
      virQEMUDriverGetDomainCapabilities(). And since some domain XMLs
      are type of 'kvm' the control gets through
      virQEMUCapsFillDomainCaps() and virHostCPUGetKVMMaxVCPUs() to
      opening /dev/kvm which may be missing on the machine we're
      running 'make check'.
      
      Previously, we did not see this issue, because it was masked. If
      building domain capabilities failed for whatever reason, we
      ignored the failure. Only v5.9.0-207-gc69e6ede uncovered the
      problem (it changed reval from 0 to -1 if
      virQEMUDriverGetDomainCapabilities() fails). Since the referenced
      commit is correct, we need to mock access to /dev/kvm in our
      tests.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      9e4445eb
    • J
      Use g_mkdtemp instead of mkdtemp · ef886986
      Ján Tomko 提交于
      Prefer the GLib version to the one from gnulib.
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
      ef886986
    • J
      qemu: Set capabilities properly for tests · b9647356
      Jonathon Jongsma 提交于
      Several tests were not specifying the necessary qemu capabilities for
      what they were testing. Due to the way that the video devices are
      currently validated, this is not causing any problems. But a change to
      video device validation in a following patch would have exposed this
      issue and resulted in multiple test failures about the domain
      configuration not supporting particular video models.
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
      b9647356
  13. 13 11月, 2019 1 次提交
  14. 12 11月, 2019 1 次提交