Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt
切换分支/标签
  1. 29 1月, 2020 8 次提交
  3. 28 1月, 2020 4 次提交
  5. 27 1月, 2020 4 次提交
    • D
      docs: add pages to support Go module package resolution · 201156ec
      由 Daniel P. Berrangé 提交于 
      Currently the libvirt Go modules are accessed by applications using
their github repository URLs. This is undesirable as we don't want
applications to have a direct dependancy on a specific source repo
location. We want to enable applications to use the Go packages via
the libvirt.org namespace.

When you do "go get libvirt.org/libvirt-go", the Go client will do an
HTTPS request to that URL, and parse the HTML content to look for a
<meta> tag which tells it where to the find the GIT repository.

   https://golang.org/cmd/go/#hdr-Remote_import_paths

This adds two pages to support this Go module resolution. They are
not linked from anywhere as we don't expect users to actually look
at them. If someone does happen upon them, there's some boilerplate
text to send them off to godoc.org for API documentation.

Since the pages we're adding have a .html extension, we will also
use a small apache config tweak on the server

    RewriteEngine on
    RewriteRule ^/libvirt-go$ /libvirt-go.html [L]
    RewriteRule ^/libvirt-go-xml$ /libvirt-go-xml.html [L]
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      201156ec
    • D
      qemu: introduce a new "virt-qemu-run" program · d6006672
      由 Daniel P. Berrangé 提交于 
      The previous "QEMU shim" proof of concept was taking an approach of only
caring about initial spawning of the QEMU process. It was then
registered with the libvirtd daemon who took over management of it. The
intent was that later libvirtd would be refactored so that the shim
retained control over the QEMU monitor and libvirt just forwarded APIs
to each shim as needed. This forwarding of APIs would require quite alot
of significant refactoring of libvirtd to achieve.

This impl thus takes a quite different approach, explicitly deciding to
keep the VMs completely separate from those seen & managed by libvirtd.
Instead it uses the new "qemu:///embed" URI scheme to embed the entire
QEMU driver in the shim, running with a custom root directory.

Once the driver is initialization, the shim starts a VM and then waits
to shutdown automatically when QEMU shuts down, or should kill QEMU if
it is terminated itself. This ought to use the AUTO_DESTROY feature but
that is not yet available in embedded mode, so we rely on installing a
few signal handlers to gracefully kill QEMU. This isn't reliable if
we crash of course, but you can restart with the same root dir.

Note this program does not expose any way to manage the QEMU process,
since there's no RPC interface enabled. It merely starts the VM and
cleans up when the guest shuts down at the end. This program is
installed to /usr/bin/virt-qemu-run enabling direct use by end users.
Most use cases will probably want to integrate the concept directly
into their respective application codebases. This standalone binary
serves as a nice demo though, and also provides a way to measure
performance of the startup process quite simply.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      d6006672
    • D
      secrets: add support for running secret driver in embedded mode · 3e9076e7
      由 Daniel P. Berrangé 提交于 
      This enables support for running the secret driver embedded to the
calling application process using a URI:

   secret:///embed?root=/some/path

When using the embedded mode with a root=/var/tmp/embed, the
driver will use the following paths:

       configDir: /var/tmp/embed/etc/secrets
        stateDir: /var/tmp/embed/run/secrets

These are identical whether the embedded driver is privileged
or unprivileged.

This compares with the system instance which uses

       configDir: /etc/libvirt/secrets
        stateDir: /var/lib/libvirt/secrets

When an embedded instance of the secret driver is open, any other
embedded drivers will automatically use the embedded secret driver.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      3e9076e7
    • 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
  7. 25 1月, 2020 2 次提交
  9. 24 1月, 2020 1 次提交
  11. 17 1月, 2020 2 次提交
  13. 16 1月, 2020 3 次提交
  15. 15 1月, 2020 2 次提交
  17. 14 1月, 2020 2 次提交
  19. 13 1月, 2020 4 次提交
  21. 10 1月, 2020 4 次提交
  23. 09 1月, 2020 1 次提交
  25. 08 1月, 2020 1 次提交
  27. 07 1月, 2020 2 次提交