1. 25 11月, 2015 8 次提交
    • D
      Allow multiple panic devices · 59fc0d06
      Dmitry Andreev 提交于
      'model' attribute was added to a panic device but only one panic
      device is allowed. This patch changes panic device presence
      from 'optional' to 'zeroOrMore'.
      59fc0d06
    • D
      qemu: add support for hv_crash feature as a panic device · ca6ddffe
      Dmitry Andreev 提交于
      Panic device type used depends on 'model' attribute.
      
      If no model is specified then device type depends on hypervisor
      and guest arch. 'pseries' model is used for pSeries guest and
      'isa' model is used in other cases.
      
      XML:
      <devices>
        <panic model='hyperv'/>
      </devices>
      
      QEMU command line:
      qemu -cpu <cpu_model>,hv_crash
      ca6ddffe
    • D
      5e8d2ebd
    • D
      conf: add 'model' attribute for panic device with values isa, pseries, hyperv · 658ec27f
      Dmitry Andreev 提交于
      Libvirt already has two types of panic devices - pvpanic and pSeries firmware.
      This patch introduces the 'model' attribute and a new type of panic device.
      
      'isa' model is for ISA pvpanic device.
      'pseries' model is a default value for pSeries guests.
      'hyperv' model is the new type. It's used for Hyper-V crash.
      
      Schema and docs are updated for the new attribute.
      658ec27f
    • D
      e5c9e032
    • G
      apparmor: add missing qemu binaries · d8ca0cbd
      Guido Günther 提交于
      This adds the qemu binaries as of 1.2.4 in Debian. It also removes a
      duplicate sparc64 entry.
      d8ca0cbd
    • L
      nodedev: report maxCount for virtual_functions capability · f391889f
      Laine Stump 提交于
      A PCI device may have the capability to setup virtual functions (VFs)
      but have them currently all disabled. Prior to this patch, if that was
      the case the the node device XML for the device wouldn't report any
      virtual_functions capability.
      
      With this patch, if a file called "sriov_totalvfs" is found in the
      device's sysfs directory, its contents will be interpreted as a
      decimal number, and that value will be reported as "maxCount" in a
      capability element of the device's XML, e.g.:
      
         <capability type='virtual_functions' maxCount='7'/>
      
      This will be reported regardless of whether or not any VFs are
      currently enabled for the device.
      
      NB: sriov_numvfs (the number of VFs currently active) is also
      available in sysfs, but that value is implied by the number of items
      in the list that is inside the capability element, so there is no
      reason to explicitly provide it as an attribute.
      
      sriov_totalvfs and sriov_numvfs are available in kernels at least as far
      back as the 2.6.32 that is in RHEL6.7, but in the case that they
      simply aren't there, libvirt will behave as it did prior to this patch
      - no maxCount will be displayed, and the virtual_functions capability
      will be absent from the device's XML when 0 VFs are enabled.
      f391889f
    • L
      conf: support reporting maxCount attribute for virtual_functions cap · 0d210c47
      Laine Stump 提交于
      Report the maximum possible number of VFs for an SRIOV PF, like this:
      
         <capability type='virtual_functions' maxCount='7'>
            ...
         </capability>
      
      I've just discovered that the virtual_functions and physical_functions
      capabilities are not supported in the virNodeDeviceParse functions,
      only in virNodeDeviceFormat (I suppose because they are only reported,
      not set from XML). This should probably be remedied, but is less
      immediately useful than the current patch.
      0d210c47
  2. 24 11月, 2015 9 次提交
  3. 23 11月, 2015 4 次提交
  4. 21 11月, 2015 2 次提交
    • J
      storage: Change virStorageBackendVolOpen to use virFileOpenAs · 5e3ad0b7
      John Ferlan 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1282288
      
      Rather than using just open on the path, allow for the possibility that
      the path to be opened resides on an NFS root-squash target and was created
      under a different uid/gid.
      
      Without using virFileOpenAs an attempt to get the volume size data may fail
      if the current user doesn't have permissions to read the volume, such as
      would be the case if mode wasn't supplied in the volume XML and the default
      VIR_STORAGE_DEFAULT_VOL_PERM_MODE (e.g. 0600) was used. Under this scenario
      the owner/group is not root:root, thus this path run under root would fail
      to open/read the volume.
      
      NB: The virFileOpenAs code using OPEN_FORK will only work when the failure
      is not EACESS/EPERM and the path resolves to a shared file system.
      5e3ad0b7
    • J
      storage: Really fix setting mode for backend exec in NFS root-squash env · ce6506b0
      John Ferlan 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1282288
      
      Although commit id '77346f27' resolves part of the problem regarding creating
      a qemu-img image in an NFS root-squash environment, it really didn't fix the
      entire problem. Unfortunately it only masked the problem. It seems qemu-img
      must open/create the image using 0644, which if used by target.perms would
      result in the chmod not being called since the mode desired and set match.
      
      Although qemu-img could conceivably ignore the mode when creating, libvirt
      has more knowledge of the environment and can make the adjustment to the
      mode far more easily by using virFileOpenAs with VIR_FILE_OPEN_FORCE_MODE.
      If that's successful, then we know on return the file will have the right
      owner and mode, so we can declare success
      ce6506b0
  5. 20 11月, 2015 5 次提交
  6. 19 11月, 2015 12 次提交