Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 09 1月, 2017 11 次提交
  3. 07 1月, 2017 6 次提交
    • 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
  5. 06 1月, 2017 5 次提交
  7. 05 1月, 2017 12 次提交
  9. 04 1月, 2017 6 次提交
    • P
      qemu: snapshot: Resume VM after live snapshot · 2e86c081
      由 Peter Krempa 提交于 
      Commit 4b951d1e missed the fact that the
VM needs to be resumed after a live external checkpoint (memory
snapshot) where the cpus would be paused by the migration rather than
libvirt.
      2e86c081
    • M
      qemuDomainCreateDevice: Be more careful about device path · dd78da09
      由 Michal Privoznik 提交于 
      Again, not something that I'd hit, but there is a chance in
theory that this might bite us. Currently the way we decide
whether or not to create /dev entry for a device is by marching
first four characters of path with "/dev". This might be not
enough. Just imagine somebody has a disk image stored under
"/devil/path/to/disk". We ought to be matching against "/dev/".
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      dd78da09
    • M
      qemuDomainAttachDeviceMknodHelper: Don't unlink() so often · ce01a2b1
      由 Michal Privoznik 提交于 
      Not that I'd encounter any bug here, but the code doesn't look
100% correct. Imagine, somebody is trying to attach a device to a
domain, and the device's /dev entry already exists in the qemu
namespace. This is handled gracefully and the control continues
with setting up ACLs and calling security manager to set up
labels. Now, if any of these steps fail, control jump on the
'cleanup' label and unlink() the file straight away. Even when it
was not us who created the file in the first place. This can be
possibly dangerous.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      ce01a2b1
    • M
      qemu: Handle EEXIST gracefully in qemuDomainCreateDevice · 3aae99fe
      由 Michal Privoznik 提交于 
      https://bugzilla.redhat.com/show_bug.cgi?id=1406837

Imagine you have a domain configured in such way that you are
assigning two PCI devices that fall into the same IOMMU group.
With mount namespace enabled what happens is that for the first
PCI device corresponding /dev/vfio/X entry is created and when
the code tries to do the same for the second mknod() fails as
/dev/vfio/X already exists:

2016-12-21 14:40:45.648+0000: 24681: error :
qemuProcessReportLogError:1792 : internal error: Process exited
prior to exec: libvirt: QEMU Driver error : Failed to make device
/var/run/libvirt/qemu/windoze.dev//vfio/22: File exists

Worse, by default there are some devices that are created in the
namespace regardless of domain configuration (e.g. /dev/null,
/dev/urandom, etc.). If one of them is set as backend for some
guest device (e.g. rng, chardev, etc.) it's the same story as
described above.

Weirdly, in attach code this is already handled.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      3aae99fe
    • A
      util: Fix syntax-check · f0af48f0
      由 Andrea Bolognani 提交于 
      Commit b9cc2483 introduced a new #define but neglected
to format it properly, thus breaking syntax-check.
      f0af48f0
    • A
      util: Turn virFirewallAddRule() into a macro · b9cc2483
      由 Andrea Bolognani 提交于 
      Clang 3.9 refuses to compile the existing code with the
following error:

  util/virfirewall.c:425:20: error: passing an object that undergoes
                             default argument promotion to 'va_start'
                             has undefined behavior [-Werror,-Wvarargs]
      va_start(args, layer);
                     ^
  util/virfirewall.c:420:37: note: parameter of type 'virFirewallLayer'
                             is declared here
                     virFirewallLayer layer,
                                      ^

This happens because 'layer' is of type virFirewallLayer, which
is an enum type and not a standard type such as eg. void* or int.

To solve the issue, turn virFirewallAddRule() from a very thin
wrapper around virFirewallAddRuleFullV() to a macro that expands
to a call to virFirewallAddRuleFull() - itself a very thin wrapper
around the aforementioned virFirewallAddRuleFullV() - with no loss
of functionality or type safety.
      b9cc2483