Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 07 9月, 2017 3 次提交
  3. 29 8月, 2017 1 次提交
  5. 18 8月, 2017 1 次提交
  7. 20 7月, 2017 1 次提交
  9. 19 7月, 2017 1 次提交
  11. 26 6月, 2017 1 次提交
  13. 14 6月, 2017 1 次提交
  15. 13 6月, 2017 1 次提交
  17. 07 6月, 2017 4 次提交
  19. 03 5月, 2017 1 次提交
    • J
      qemu: Fix persistent migration of transient domains · 59307fad
      由 Jiri Denemark 提交于 
      While fixing a bug with incorrectly freed memory in commit
v3.1.0-399-g5498aa29, I accidentally broke persistent migration of
transient domains. Before adding qemuDomainDefCopy in the path, the code
just took NULL from vm->newDef and used it as the persistent def, which
resulted in no persistent XML being sent in the migration cookie. This
scenario is perfectly valid and the destination correctly handles it by
using the incoming live definition and storing it as the persistent one.

After the mentioned commit libvirtd would just segfault in the described
scenario.

https://bugzilla.redhat.com/show_bug.cgi?id=1446205Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      59307fad
  21. 02 5月, 2017 1 次提交
  23. 27 4月, 2017 4 次提交
  25. 18 4月, 2017 1 次提交
    • P
      qemu: migration: Skip cache=none check for disks which are storage-migrated · 41e9f54d
      由 Peter Krempa 提交于 
      Since the disks are copied by qemu, there's no need to enforce
cache=none. Thankfully the code that added qemuMigrateDisk did not break
existing configs, since if you don't select any disk to migrate
explicitly the code behaves sanely.

The logic for determining whether a disk should be migrated is
open-coded since using qemuMigrateDisk twice would be semantically
incorrect.
      41e9f54d
  27. 13 4月, 2017 2 次提交
  29. 07 4月, 2017 6 次提交
  31. 05 4月, 2017 2 次提交
  33. 03 4月, 2017 1 次提交
    • M
      virGetDomain: Set domain ID too · 5683b213
      由 Michal Privoznik 提交于 
      So far our code is full of the following pattern:

  dom = virGetDomain(conn, name, uuid)
  if (dom)
      dom->id = 42;

There is no reasong why it couldn't be just:

  dom = virGetDomain(conn, name, uuid, id);

After all, client domain representation consists of tuple (name,
uuid, id).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      5683b213
  35. 28 3月, 2017 4 次提交
  37. 27 3月, 2017 1 次提交
  39. 26 3月, 2017 1 次提交
    • R
      qemu: fix build with clang · 4035baeb
      由 Roman Bogorodskiy 提交于 
      qemuMigrationResetTLS() does not initialize 'ret' by default,
so when it jumps to 'cleanup' on error, the 'ret' variable will be
uninitialized, which clang complains about.

Set it to '-1' by default.
      4035baeb
  41. 25 3月, 2017 2 次提交
    • J
      qemu: Set up the migration TLS objects for source · a69e266d
      由 John Ferlan 提交于 
      https://bugzilla.redhat.com/show_bug.cgi?id=1300769

If the migration flags indicate this migration will be using TLS,
then while we have connection in the Begin phase check and setup the
TLS environment that will be used by virMigrationRun during the Perform
phase for the source to configure TLS.

Processing adds an "-object tls-creds-x509,endpoint=client,..." and
possibly an "-object secret,..." to handle the passphrase response.

Then it sets the 'tls-creds' and possibly 'tls-hostname' migration
parameters.

The qemuMigrateCancel will clean up and reset the environment as it
was originally found.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      a69e266d
    • J
      qemu: Set up the migration TLS objects for target · 1a6b6d9a
      由 John Ferlan 提交于 
      If the migration flags indicate this migration will be using TLS,
then set up the destination during the prepare phase once the target
domain has been started to add the TLS objects to perform the migration.

This will create at least an "-object tls-creds-x509,endpoint=server,..."
for TLS credentials and potentially an "-object secret,..." to handle the
passphrase response to access the TLS credentials. The alias/id used for
the TLS objects will contain "libvirt_migrate".

Once the objects are created, the code will set the "tls-creds" and
"tls-hostname" migration parameters to signify usage of TLS.

During the Finish phase we'll be sure to attempt to clear the
migration parameters and delete those objects (whether or not they
were created). We'll also perform the same reset during recovery
if we've reached FINISH3.

If the migration isn't using TLS, then be sure to check if the
migration parameters exist and clear them if so.
      1a6b6d9a