1. 25 2月, 2020 1 次提交
  2. 24 2月, 2020 1 次提交
  3. 23 2月, 2020 8 次提交
  4. 19 2月, 2020 1 次提交
  5. 18 2月, 2020 1 次提交
  6. 10 2月, 2020 2 次提交
  7. 07 2月, 2020 1 次提交
    • 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
  8. 04 2月, 2020 5 次提交
  9. 30 1月, 2020 1 次提交
  10. 29 1月, 2020 6 次提交
  11. 28 1月, 2020 1 次提交
  12. 27 1月, 2020 4 次提交
    • P
      qemu: snapshot: Prevent too-nested domain XML when doing inactive snapshot · b168fa88
      Peter Krempa 提交于
      Similarly to 510d154a we need to prevent
      doing too deeply nested backing chains and reject them with a sane error
      message.
      
      Add a loop to go through the snapshots prior to attempting actually
      creating them to prevent some possible inconsistent scenarios.
      
      We don't need to do it when reusing backing chains as we'll be
      re-detecting the backing chain in that case anyways.
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      b168fa88
    • P
      qemu: snapshot: Always rewrite backingStore data when reusing existing images · 8e9e73a9
      Peter Krempa 提交于
      Don't adopt the backing store data when reusing images provided by the
      user. This will force a backing chain re-probe as users might have
      passed in something unexpected in the overlay where our view of the
      backing chain would not correspond.
      
      This is done only for inactive snapshots as there we have way less
      verification.
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      8e9e73a9
    • D
      qemu: add support for running QEMU driver in embedded mode · 068efae5
      Daniel P. Berrangé 提交于
      This enables support for running QEMU embedded to the calling
      application process using a URI:
      
         qemu:///embed?root=/some/path
      
      Note that it is important to keep the path reasonably short to
      avoid risk of hitting the limit on UNIX socket path names
      which is 108 characters.
      
      When using the embedded mode with a root=/var/tmp/embed, the
      driver will use the following paths:
      
                      logDir: /var/tmp/embed/log/qemu
                 swtpmLogDir: /var/tmp/embed/log/swtpm
               configBaseDir: /var/tmp/embed/etc/qemu
                    stateDir: /var/tmp/embed/run/qemu
               swtpmStateDir: /var/tmp/embed/run/swtpm
                    cacheDir: /var/tmp/embed/cache/qemu
                      libDir: /var/tmp/embed/lib/qemu
             swtpmStorageDir: /var/tmp/embed/lib/swtpm
       defaultTLSx509certdir: /var/tmp/embed/etc/pki/qemu
      
      These are identical whether the embedded driver is privileged
      or unprivileged.
      
      This compares with the system instance which uses
      
                      logDir: /var/log/libvirt/qemu
                 swtpmLogDir: /var/log/swtpm/libvirt/qemu
               configBaseDir: /etc/libvirt/qemu
                    stateDir: /run/libvirt/qemu
               swtpmStateDir: /run/libvirt/qemu/swtpm
                    cacheDir: /var/cache/libvirt/qemu
                      libDir: /var/lib/libvirt/qemu
             swtpmStorageDir: /var/lib/libvirt/swtpm
       defaultTLSx509certdir: /etc/pki/qemu
      
      At this time all features present in the QEMU driver are available when
      running in embedded mode, availability matching whether the embedded
      driver is privileged or unprivileged.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      068efae5
    • D
      libvirt: pass a directory path into drivers for embedded usage · 207709a0
      Daniel P. Berrangé 提交于
      The intent here is to allow the virt drivers to be run directly embedded
      in an arbitrary process without interfering with libvirtd. To achieve
      this they need to store all their configuration & state in a separate
      directory tree from the main system or session libvirtd instances.
      
      This can be useful for doing testing of the virt drivers in "make check"
      without interfering with the user's own libvirtd instances.
      
      It can also be used for applications using KVM/QEMU as a piece of
      infrastructure to build an service, rather than for general purpose
      OS hosting. A long standing example is libguestfs, which would prefer
      if its temporary VMs did show up in the main libvirtd VM list, because
      this confuses apps such as OpenStack Nova. A more recent example would
      be Kata which is using KVM as a technology to build containers.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      207709a0
  13. 24 1月, 2020 3 次提交
  14. 23 1月, 2020 1 次提交
  15. 20 1月, 2020 1 次提交
  16. 17 1月, 2020 2 次提交
  17. 16 1月, 2020 1 次提交