Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 28 9月, 2017 3 次提交
    • A
      conf: Introduce TLS options for VxHS block device clients · bd6fdcd8
      由 Ashish Mittal 提交于 
      Add a new TLS X.509 certificate type - "vxhs". This will handle the
creation of a TLS certificate capability for properly configured
VxHS network block device clients.

The following describes the behavior of TLS for VxHS block device:

  (1) Two new options have been added in /etc/libvirt/qemu.conf
      to control TLS behavior with VxHS block devices
      "vxhs_tls" and "vxhs_tls_x509_cert_dir".
  (2) Setting "vxhs_tls=1" in /etc/libvirt/qemu.conf will enable
      TLS for VxHS block devices.
  (3) "vxhs_tls_x509_cert_dir" can be set to the full path where the
      TLS CA certificate and the client certificate and keys are saved.
      If this value is missing, the "default_tls_x509_cert_dir" will be
      used instead. If the environment is not configured properly the
      authentication to the VxHS server will fail.
Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      bd6fdcd8
    • J
      nwfilter: Fix possible segfault on sometimes consumed variable · 6209bb32
      由 John Ferlan 提交于 
      The virNWFilterIPAddrMapAddIPAddr code can consume the @addr parameter
on success when the @ifname is found in the ipAddressMap->hashTable
hash table in the call to virNWFilterVarValueAddValue; however, if
not found in the hash table, then @addr is formatted into a @val
which is stored in the table and on return the caller would be
expected to free @addr.

Thus, the caller has no way to determine on success whether @addr was
consumed, so in order to fix this create a @tmp variable which will
be stored/consumed when virNWFilterVarValueAddValue succeeds. That way
the caller can free @addr whether the function returns success or failure.
      6209bb32
    • P
      rpc: for messages with FDs always decode count of FDs from the message · 5c52aed1
      由 Pavel Hrdina 提交于 
      The packet with passed FD has the following format:

    --------------------------
    | len | header | payload |
    --------------------------

where "payload" has an additional count of FDs before the actual data:

    ------------------
    | nfds | payload |
    ------------------

When the packet is received we parse the "header", which as a side
effect updates msg->bufferOffset to point to the beginning of "payload".
If the message call contains FDs, we need to also parse the count of
FDs, which also updates the msg->bufferOffset.

The issue here is that when we attempt to read the FDs data from the
socket and we receive EAGAIN we finish the reading and call poll()
to wait for the data the we need.  When the data arrives we already have
the packet in our buffer so we read the "header" again but this time
we don't read the count of FDs because we already have it stored.

That means that the msg->bufferOffset is not updated to point to the
actual beginning of the payload data, but it points to the count of
FDs.  After all FDs are processed we dispatch the message to process
it and decode the payload.  Since the msg->bufferOffset points to wrong
data, we decode the wrong payload and the API call fails with
error messages:

    Domain not found: no domain with matching uuid '67656e65-7269-6300-0c87-5003ca6941f2' ()

Broken by commit 133c511b which fixed a FD and memory leak.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      5c52aed1
  3. 27 9月, 2017 12 次提交
  5. 26 9月, 2017 3 次提交
  7. 25 9月, 2017 4 次提交
  9. 22 9月, 2017 12 次提交
  11. 21 9月, 2017 6 次提交
    • M
      qemu: Introduce a wrapper over virFileWrapperFdClose · 92524d3e
      由 Michal Privoznik 提交于 
      https://bugzilla.redhat.com/show_bug.cgi?id=1448268

When migrating to a file (e.g. when doing 'virsh save file'),
couple of things are happening in the thread that is executing
the API:

1) the domain obj is locked
2) iohelper is spawned as a separate process to handle all I/O
3) the thread waits for iohelper to finish
4) the domain obj is unlocked

Now, the problem is that while the thread waits in step 3 for
iohelper to finish this may take ages because iohelper calls
fdatasync(). And unfortunately, we are waiting the whole time
with the domain locked. So if another thread wants to jump in and
say copy the domain name ('virsh list' for instance), they are
stuck.

The solution is to unlock the domain whenever waiting for I/O and
lock it back again when it finished.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      92524d3e
    • J
      qemu: Be more selective when determining cdrom for taint messaging · ed2a741e
      由 John Ferlan 提交于 
      https://bugzilla.redhat.com/show_bug.cgi?id=1471225

Commit id '99a2d6af' was a bit too aggressive with determining whether
the provided path was a "physical" cd-rom in order to generate a taint
message due to the possibility of some guest and host trying to control
the tray. For cd-rom guest devices backed to some VIR_STORAGE_TYPE_FILE
storage, this wouldn't be a problem and as such it shouldn't be a problem
for guest devices using some sort of block device on the host such as
iSCSI, LVM, or a Disk pool would present.

So before issuing a taint message, let's check if the provided path of
the VIR_STORAGE_TYPE_BLOCK backed device is a "known" physical cdrom name
by comparing the beginning of the path w/ "/dev/cdrom" and "/dev/sr".
Also since it's possible the provided path could resolve to some /dev/srN
device, let's get that path as well and perform the same check.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      ed2a741e
    • M
      qemuBuildHostNetStr: Don't leak @addr · 57d8afcf
      由 Michal Privoznik 提交于 
      The virSocketAddrFormat() allocates the string and it's caller
responsibility to free it afterwards.

==28857== 11 bytes in 1 blocks are definitely lost in loss record 37 of 168
==28857==    at 0x4C2BEDF: malloc (vg_replace_malloc.c:299)
==28857==    by 0x9A81D79: strdup (in /lib64/libc-2.23.so)
==28857==    by 0x5DA3BF0: virStrdup (virstring.c:902)
==28857==    by 0x5D96182: virSocketAddrFormatFull (virsocketaddr.c:427)
==28857==    by 0x5D95E13: virSocketAddrFormat (virsocketaddr.c:352)
==28857==    by 0x5706890: qemuBuildHostNetStr (qemu_command.c:3891)
==28857==    by 0x57138D3: qemuBuildInterfaceCommandLine (qemu_command.c:8597)
==28857==    by 0x5713D6A: qemuBuildNetCommandLine (qemu_command.c:8699)
==28857==    by 0x57176F6: qemuBuildCommandLine (qemu_command.c:10027)
==28857==    by 0x5769D61: qemuProcessCreatePretendCmd (qemu_process.c:6004)
==28857==    by 0x4056EC: testCompareXMLToArgv (qemuxml2argvtest.c:502)
==28857==    by 0x41DF40: virTestRun (testutils.c:180)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      57d8afcf
    • J
      qemu: Don't update CPU when formatting live def · 06f75ff2
      由 Jiri Denemark 提交于 
      Since commit v2.2.0-199-g7ce711a3 libvirt stores an updated guest CPU
in domain's live definition and there's no need to update it every time
we want to format the definition. The commit itself tried to address
this in qemuDomainFormatXML, but forgot to fix qemuDomainDefFormatLive.
Not to mention that masking a previously set flag is only acceptable if
the flag was set by a public API user. Internally, libvirt should have
never set the flag in the first place.

https://bugzilla.redhat.com/show_bug.cgi?id=1485022Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      06f75ff2
    • J
      qemu: Use correct host model for updating guest cpu · 7e874326
      由 Jiri Denemark 提交于 
      When a user requested a domain XML description with
VIR_DOMAIN_XML_UPDATE_CPU flag, libvirt would use the host CPU
definition from host capabilities rather than the one which will
actually be used once the domain is started.

https://bugzilla.redhat.com/show_bug.cgi?id=1481309Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      7e874326
    • J
      conf: Drop unused VIR_DOMAIN_DEF_FORMAT_UPDATE_CPU · 43a90eb7
      由 Jiri Denemark 提交于 
      The only real usage of this flag was removed by "cpu_conf: Drop
updateCPU from virCPUDefFormat".
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      43a90eb7