Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 23 7月, 2018 1 次提交
    • D
      tests: fix TLS handshake failure with TLS 1.3 · cf92b90e
      由 Daniel P. Berrangé 提交于 
      When gnutls negotiates TLS 1.3 instead of 1.2, the order of messages
sent by the handshake changes. This exposed a logic bug in the test
suite which caused us to wait for the server to see handshake
completion, but not wait for the client to see completion. The result
was the client didn't receive the certificate for verification and the
test failed.

This is exposed in Fedora 29 rawhide which has just enabled TLS 1.3 in
its GNUTLS builds.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      cf92b90e
  3. 19 7月, 2018 6 次提交
  5. 18 7月, 2018 5 次提交
  7. 17 7月, 2018 2 次提交
  9. 13 7月, 2018 6 次提交
  11. 10 7月, 2018 9 次提交
  13. 09 7月, 2018 1 次提交
    • E
      qemu: command: Fix building of the SDL display command line · ff767f08
      由 Erik Skultety 提交于 
      QEMU uses a shorthand '-sdl' which maps to '-display sdl'. However, if
there are any options to be passed to SDL, the full command version must
be used. Everything seemingly worked for us until commit 5038b300
introduced OpenGL support for SDL and added ',gl=on/off' option which as
mentioned above could have never worked with the shorthand version of
the command. Indeed starting a domain with an SDL display and OpenGL
enabled, QEMU produces a rather cryptic error:

-sdl: Could not open 'gl=on': No such file or directory

This patch provides fixes to both the SDL cmdline generation and the
test suite.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      ff767f08
  15. 06 7月, 2018 2 次提交
  17. 03 7月, 2018 6 次提交
  19. 27 6月, 2018 2 次提交
    • J
      storage: Add support for using inputvol for encryption · 39cef12a
      由 John Ferlan 提交于 
      Starting with QEMU 2.9, encryption convert processing requires
a multi-step process in order to generate an encrypted image from
some non encrypted raw image.

Processing requires to first create an encrypted image using the
sizing parameters from the input source and second to use the
--image-opts, -n, and --target-image-opts options along with inline
driver options to describe the input and output files, generating
two commands such as:

  $ qemu-img create -f luks \
      --object secret,id=demo.img_encrypt0,file=/path/to/secretFile \
      -o key-secret=demo.img_encrypt0 \
      demo.img 500K
  Formatting 'demo.img', fmt=luks size=512000 key-secret=demo.img_encrypt0
  $ qemu-img convert --image-opts -n --target-image-opts \
      --object secret,id=demo.img_encrypt0,file=/path/to/secretFile \
      driver=raw,file.filename=sparse.img \
      driver=luks,file.filename=demo.img,key-secret=demo.img_encrypt0
  $

This patch handles the convert processing by running the processing
in a do..while loop essentially reusing the existing create logic and
arguments to create the target vol from the inputvol and then converting
the inputvol using new arguments.

This then allows the following virsh command to work properly:

  virsh vol-create-from default encrypt1-luks.xml data.img --inputpool default

where encrypt1-luks.xml would provided the path and secret for
the new image, while data.img would be the source image.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
      39cef12a
    • J
      storage: Disallow create/resize of qcow2 encrypted images · 8f83af68
      由 John Ferlan 提交于 
      https://bugzilla.redhat.com/show_bug.cgi?id=1526382

Since commit c4eedd79 disallowed qcow2 encrypted images to be
used for domains, it no longer makes sense to allow a qcow2
encrypted volume to be created or resized.

Add a test that will exhibit the failure of creation as well
as the xml2xml validation of the format still being correct.

Update the documentation to note the removal of the capability
to create and use qcow/default encrypted volumes.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
      8f83af68