Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 11 2月, 2020 26 次提交
  3. 10 2月, 2020 2 次提交
  5. 09 2月, 2020 1 次提交
  7. 07 2月, 2020 11 次提交
    • D
      gnulib: delete all gnulib integration · 2621d48f
      由 Daniel P. Berrangé 提交于 
      This deletes all trace of gnulib from libvirt. We still
have the keycodemapdb submodule to deal with. The simple
solution taken was to update it when running autogen.sh.

Previously gnulib could auto-trigger refresh when running
'make' too. We could figure out a solution for this, but
with the pending meson rewrite it isn't worth worrying
about, given how infrequently keycodemapdb changes.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      2621d48f
    • D
      util: delete the poll() based event loop impl · 55fe8110
      由 Daniel P. Berrangé 提交于 
      It is no longer require since switching to the GLib based
event loop impl.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      55fe8110
    • D
      util: switch to use the GLib event loop impl · 946a2527
      由 Daniel P. Berrangé 提交于 
      This sets the GLib event loop as the impl when calling
virEventRegisterDefaultImpl(). This remains a private
impl detail of libvirt, so applications must *NOT*
assume that a call to virEventRegisterDefaultImpl()
results in a GLib based event loop.

They should continue to use the libvirt-glib API
gvir_event_register() if they explicitly want to guarantee
a GLib event loop.

This follows the general principal that the libvirt public
API should not expose the fact that GLib is being used
internally.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      946a2527
    • D
      util: import an event loop impl based on GMainContext · f8ab47cb
      由 Daniel P. Berrangé 提交于 
      The libvirt-glib project has provided a GMainContext based
event loop impl for applications. This imports it and sets
it up for use by libvirt as the primary event loop. This
remains a private impl detail of libvirt.

IOW, applications must *NOT* assume that a call to
"virEventRegisterDefaultImpl" results in a GLib based
event loop. They should continue to use the libvirt-glib
API gvir_event_register() if they explicitly want to
guarantee a GLib event loop.

This follows the general principle that the libvirt public
API should not expose the fact that GLib is being used
internally.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      f8ab47cb
    • D
      rpc: convert RPC client to use GMainLoop instead of poll · 7d4350bc
      由 Daniel P. Berrangé 提交于 
      To eliminate the dependancy on GNULIB's poll impl, we need
to change the RPC client code to use GMainLoop. We don't
really want to use GIOChannel, but it provides the most
convenient way to do socket event watches with Windows
portability. The other alternative would be to use GSocket
but that is a much more complex change affecting libvirt
more broadly.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      7d4350bc
    • D
      src: introduce helper API for creating GSource for socket · 5de317b8
      由 Daniel P. Berrangé 提交于 
      We need to be able to create event loop watches using the
GSource API for sockets. GIOChannel is able todo this, but
we don't want to use the GIOChannel APIs for reading/writing,
and testing shows just using its GSource APIs is unreliable
on Windows.

This patch thus creates a standalone helper API for creating
a GSource for a socket file descriptor. This impl is derived
from code in QEMU's io/channel-watch.c file that was written
by myself & Paolo Bonzini & thus under Red Hat copyright.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      5de317b8
    • D
      tools: rewrite interactive job monitoring logic · dc0771cf
      由 Daniel P. Berrangé 提交于 
      For long running jobs (save, managed save, dump & live migrate)
virsh runs a background thread for executing the job and then
has the main thread catch Ctrl-C for graceful shutdown, as well
as displaying progress info.

The monitoring code is written using poll, with a pipe used
to get the completion status from the thread. Using a pipe
and poll is problematic for Windows portability. This rewrites
the code to use a GMainLoop instance for monitoring stdin and
doing progress updates. The use of a pipe is entirely eliminated,
instead there is just a shared variable between both threads
containing the job completion status.

No mutex locking is used because the background thread writes
to the variable only when the main loop is still running,
while the foreground thread only reads it after the main loop
has exited.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      dc0771cf
    • D
      tests: avoid referencing stale readdir pointer · 29c4a3c7
      由 Daniel P. Berrangé 提交于 
      The contents of 'struct dirent' are only valid until the next call to
readdir() or closedir(). It is thus invalid to save a pointer to the
'd_name' field. Somehow this hasn't affected the test suite until
recently when FreeBSD 12 started showing use of uninitialized memory
resulting in test failures.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      29c4a3c7
    • Z
      qemu: support Panic Crashloaded event handling · 26badd13
      由 zhenwei pi 提交于 
      Pvpanic device supports bit 1 as crashloaded event, it means that
guest actually panicked and run kexec to handle error by guest side.

Handle crashloaded as a lifecyle event in libvirt.

Test case:
Guest side:
before testing, we need make sure kdump is enabled,
1, build new pvpanic driver (with commit from upstream
   e0b9a42735f2672ca2764cfbea6e55a81098d5ba
   191941692a3d1b6a9614502b279be062926b70f5)
2, insmod new kmod
3, enable crash_kexec_post_notifiers,
  # echo 1 > /sys/module/kernel/parameters/crash_kexec_post_notifiers
4, trigger kernel panic
  # echo 1 > /proc/sys/kernel/sysrq
  # echo c > /proc/sysrq-trigger

Host side:
1, build new qemu with pvpanic patches (with commit from upstream
   600d7b47e8f5085919fd1d1157f25950ea8dbc11
   7dc58deea79a343ac3adc5cadb97215086054c86)
2, build libvirt with this patch
3, handle lifecycle event and trigger guest side panic
  # virsh event stretch --event lifecycle
  event 'lifecycle' for domain stretch: Crashed Crashloaded
  events received: 1
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Nzhenwei pi <pizhenwei@bytedance.com>
      26badd13
    • D
      docs: render class="literal" with monospace font · 039787c7
      由 Daniel P. Berrangé 提交于 
      When using ``....`` in RST, this results in <span class="literal">...</span>
instead of <code>...</code>. We thus need an extra rule to render it
with a monospace font. Colouring a light gray also helps the text
stand out a little more and matches background of <pre> blocks.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      039787c7
    • J
      qemu_capabilities: Disable CPU models on old s390 machine types · c6ff3d15
      由 Jiri Denemark 提交于 
      Starting a KVM domain on s390 with old machine type (such as
s390-ccw-virtio-2.5) and without any guest CPU model configured fails
with

    CPU models are not available: KVM doesn't support CPU models

QEMU error. This is cause by libvirt using host-model CPU as the default
CPU based on QEMU reporting "host" CPU model as being the default one
(see commit v5.9.0-402-g24d82022: qemu: Use host-model CPU on s390 by
default). However, even though both QEMU and KVM support CPU models on
s390 and QEMU can give us the host-model CPU, we can't use it with old
machine types which only support -cpu host.

https://bugzilla.redhat.com/show_bug.cgi?id=1795651Reported-by: NChristian Ehrhardt <paelzer@gmail.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      c6ff3d15