1. 10 1月, 2017 17 次提交
  2. 09 1月, 2017 13 次提交
  3. 07 1月, 2017 8 次提交
    • C
      virsh: Fix grammar - s/rather then/rather than · 96b1f091
      Chen Hanxiao 提交于
      Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
      96b1f091
    • M
      tests: Add "no-kvm-pit-device" testcase · 245d9ba2
      Maxim Nestratov 提交于
      Add a test case for when the QEMU_CAPS_NO_KVM_PIT capability is set.
      This capability is mutually exclusive to QEMU_CAPS_KVM_PIT_TICK_POLICY
      and results in the same output regardless of whether "discard" or
      "delay" was specified in the guest XML for 'tickpolicy'.
      Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
      245d9ba2
    • M
      qemu: Allow to specify pit timer tick policy=discard · af78cb04
      Maxim Nestratov 提交于
      Separate out the "policy=discard" into it's own specific
      qemu command line.
      
      We'll rename "kvm-pit-device" test case to be "kvm-pit-discard"
      since it has the syntax we'd be using.
      Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
      af78cb04
    • M
      qemu: Fix pit timer tick policy=delay · ef5c8bb4
      Maxim Nestratov 提交于
      By a mistake, for the VIR_DOMAIN_TIMER_TICKPOLICY_DELAY qemu
      command line creation, 'discard' was used instead of 'delay'
      in commit id '1569fa14'.
      
      Test "kvm-pit-delay" is fixed accordingly to show the correct
      option being generated.
      
      Remove the (now) redundant kvm-pit-device tests. As it turns
      out there is no need to specify both QEMU_CAPS_NO_KVM_PIT and
      QEMU_CAPS_KVM_PIT_TICK_POLICY since they are mutually exclusive
      and "kvm-pit-device" becomes just the same as "kvm-pit-delay".
      Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
      ef5c8bb4
    • J
      iscsi: Add parent wwnn/wwpn or fabric capability for createVport · 78be2e8b
      John Ferlan 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1349696
      
      As it turns out using only the 'parent' to achieve the goal of a
      consistent vHBA parent has issues with reboots where the scsi_hostX
      parent could change to scsi_hostY causing either failure to create
      the vHBA or usage of the wrong HBA for our vHBA.
      
      Thus add the ability to search for the "parent" by the parent wwnn/
      wwpn values or just a fabric_name if someone only cares to ensure
      usage of the same SAN for the vHBA.
      78be2e8b
    • J
      util: Introduce virGetFCHostNameByFabricWWN · 8366cb0a
      John Ferlan 提交于
      Create a utility routine in order to read the scsi_host fabric_name files
      looking for a match to a passed fabric_name
      8366cb0a
    • 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
  4. 06 1月, 2017 2 次提交