Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 11 5月, 2017 4 次提交
    • P
      qemu: process: Clean up priv->migTLSAlias · b4b88049
      由 Peter Krempa 提交于 
      The alias would be leaked, since it's not freed on the vm stop path.

(cherry picked from commit 8c1fee5f)
      b4b88049
    • P
      qemu: process: Don't leak priv->usbaddrs after VM restart · 849fbcf7
      由 Peter Krempa 提交于 
      Since the private data structure is not freed upon stopping a VM, the
usbaddrs pointer would be leaked:

==15388== 136 (16 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 893 of 1,019
==15388==    at 0x4C2CF55: calloc (vg_replace_malloc.c:711)
==15388==    by 0x54BF64A: virAlloc (viralloc.c:144)
==15388==    by 0x5547588: virDomainUSBAddressSetCreate (domain_addr.c:1608)
==15388==    by 0x144D38A2: qemuDomainAssignUSBAddresses (qemu_domain_address.c:2458)
==15388==    by 0x144D38A2: qemuDomainAssignAddresses (qemu_domain_address.c:2515)
==15388==    by 0x144ED1E3: qemuProcessPrepareDomain (qemu_process.c:5398)
==15388==    by 0x144F51FF: qemuProcessStart (qemu_process.c:5979)
[...]

(cherry picked from commit 3ab802d6)
      849fbcf7
    • P
      qemu: process: Clean automatic NUMA/cpu pinning information on shutdown · 0b99253a
      由 Peter Krempa 提交于 
      Clean the stale data after shutting down the VM. Otherwise the data
would be leaked on next VM start. This happens due to the fact that the
private data object is not freed on destroy of the VM.

(cherry picked from commit 1730cdc6)
      0b99253a
    • J
      qemu: Properly reset TLS in qemuProcessRecoverMigrationIn · bca95e75
      由 Jiri Denemark 提交于 
      There is no async job running when a freshly started libvirtd is trying
to recover from an interrupted incoming migration. While at it, let's
call qemuMigrationResetTLS every time we don't kill the domain. This is
not strictly necessary since TLS is not supported when v2 migration
protocol is used, but doing so makes more sense.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit 59b28eca)
      bca95e75
  3. 06 4月, 2017 1 次提交
    • J
      qemu: Fix regression when hyperv/vendor_id feature is used · 04535336
      由 Jiri Denemark 提交于 
      qemuProcessVerifyHypervFeatures is supposed to check whether all
requested hyperv features were actually honored by QEMU/KVM. This is
done by checking the corresponding CPUID bits reported by the virtual
CPU. In other words, it doesn't work for string properties, such as
VIR_DOMAIN_HYPERV_VENDOR_ID (there is no CPUID bit we could check). We
could theoretically check all 96 bits corresponding to the vendor
string, but luckily we don't have to check the feature at all. If QEMU
is too old to support hyperv features, the domain won't even start.
Otherwise, it is always supported.

Without this patch, libvirt refuses to start a domain which contains

  <features>
    <hyperv>
      <vendor_id state='on' value='...'/>
    </hyperv>
  </features>

reporting internal error: "unknown CPU feature __kvm_hv_vendor_id.

This regression was introduced by commit v3.1.0-186-ge9dbe701, which
(by fixing the virCPUDataCheckFeature condition in
qemuProcessVerifyHypervFeatures) revealed an old bug in the feature
verification code. It's been there ever since the verification was
implemented by commit v1.3.3-rc1-5-g95bbe4bf, which effectively did not
check VIR_DOMAIN_HYPERV_VENDOR_ID at all.

https://bugzilla.redhat.com/show_bug.cgi?id=1439424Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit ae102b5d)
      04535336
  5. 27 3月, 2017 3 次提交
  7. 25 3月, 2017 1 次提交
    • J
      qemu: Set up the migration TLS objects for target · 1a6b6d9a
      由 John Ferlan 提交于 
      If the migration flags indicate this migration will be using TLS,
then set up the destination during the prepare phase once the target
domain has been started to add the TLS objects to perform the migration.

This will create at least an "-object tls-creds-x509,endpoint=server,..."
for TLS credentials and potentially an "-object secret,..." to handle the
passphrase response to access the TLS credentials. The alias/id used for
the TLS objects will contain "libvirt_migrate".

Once the objects are created, the code will set the "tls-creds" and
"tls-hostname" migration parameters to signify usage of TLS.

During the Finish phase we'll be sure to attempt to clear the
migration parameters and delete those objects (whether or not they
were created). We'll also perform the same reset during recovery
if we've reached FINISH3.

If the migration isn't using TLS, then be sure to check if the
migration parameters exist and clear them if so.
      1a6b6d9a
  9. 20 3月, 2017 1 次提交
  11. 17 3月, 2017 7 次提交
  13. 16 3月, 2017 1 次提交
  15. 10 3月, 2017 1 次提交
    • M
      qemuProcessHandleMonitorEOF: Disable namespace for domain · e915942b
      由 Michal Privoznik 提交于 
      https://bugzilla.redhat.com/show_bug.cgi?id=1430634

If a qemu process has died, we get EOF on its monitor. At this
point, since qemu process was the only one running in the
namespace kernel has already cleaned the namespace up. Any
attempt of ours to enter it has to fail.

This really happened in the bug linked above. We've tried to
attach a disk to qemu and while we were in the monitor talking to
qemu it just died. Therefore our code tried to do some roll back
(e.g. deny the device in cgroups again, restore labels, etc.).
However, during the roll back (esp. when restoring labels) we
still thought that domain has a namespace. So we used secdriver's
transactions. This failed as there is no namespace to enter.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      e915942b
  17. 08 3月, 2017 1 次提交
  19. 06 3月, 2017 1 次提交
    • M
      qemu: Enforce qemuSecurity wrappers · 4da534c0
      由 Michal Privoznik 提交于 
      Now that we have some qemuSecurity wrappers over
virSecurityManager APIs, lets make sure everybody sticks with
them. We have them for a reason and calling virSecurityManager
API directly instead of wrapper may lead into accidentally
labelling a file on the host instead of namespace.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      4da534c0
  21. 04 3月, 2017 1 次提交
  23. 24 2月, 2017 3 次提交
  25. 23 2月, 2017 1 次提交
  27. 21 2月, 2017 6 次提交
  29. 16 2月, 2017 1 次提交
  31. 09 2月, 2017 1 次提交
  33. 17 1月, 2017 1 次提交
  35. 10 1月, 2017 1 次提交
  37. 05 1月, 2017 2 次提交
  39. 15 12月, 2016 2 次提交
    • P
      qemu: monitor: Don't resume lockspaces in resume event handler · e8f167a6
      由 Peter Krempa 提交于 
      After qemu delivers the resume event it's already running and thus it's
too late to enter lockspaces since it may already have modified the
disk. The code only creates false log entries in the case when locking
is enabled. The lockspace needs to be acquired prior to starting cpus.
      e8f167a6
    • M
      qemu: Enter the namespace on relabelling · eadaa975
      由 Michal Privoznik 提交于 
      Instead of trying to fix our security drivers, we can use a
simple trick to relabel paths in both namespace and the host.
I mean, if we enter the namespace some paths are still shared
with the host so any change done to them is visible from the host
too.
Therefore, we can just enter the namespace and call
SetAllLabel()/RestoreAllLabel() from there. Yes, it has slight
overhead because we have to fork in order to enter the namespace.
But on the other hand, no complexity is added to our code.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      eadaa975