Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 07 4月, 2017 5 次提交
  3. 05 4月, 2017 2 次提交
  5. 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
  7. 28 3月, 2017 4 次提交
  9. 27 3月, 2017 1 次提交
  11. 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
  13. 25 3月, 2017 3 次提交
    • 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
    • J
      qemu: Add TLS params to _qemuMonitorMigrationParams · 3d06cb96
      由 John Ferlan 提交于 
      Add the fields to support setting tls-creds and tls-hostname during
a migration (either source or target). Modify the query migration
function to check for the presence and set the field for future
consumers to determine which of 3 conditions is being met (NULL,
present and set to "", or present and sent to something). These
correspond to qemu commit id '4af245dc3' which added support to
default the value to "" and allow setting (or resetting) to ""
in order to disable. This reset option allows libvirt to properly
use the tls-creds and tls-hostname parameters.

Modify code paths that either allocate or use stack space in order
to call qemuMigrationParamsClear or qemuMigrationParamsFree for cleanup.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      3d06cb96
  15. 24 3月, 2017 1 次提交
  17. 23 3月, 2017 1 次提交
  19. 06 3月, 2017 1 次提交
    • M
      qemu: Enforce qemuSecurity wrappers · 4da534c0
      由 Michal Privoznik 提交于 
      Now that we have some qemuSecurity wrappers over
virSecurityManager APIs, lets make sure everybody sticks with
them. We have them for a reason and calling virSecurityManager
API directly instead of wrapper may lead into accidentally
labelling a file on the host instead of namespace.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      4da534c0
  21. 16 2月, 2017 1 次提交
  23. 21 12月, 2016 1 次提交
  25. 29 11月, 2016 1 次提交
  27. 23 11月, 2016 1 次提交
    • N
      qemu: agent: handle agent connection errors in one place · 851ae08e
      由 Nikolay Shirokovskiy 提交于 
      qemuConnectAgent return -1 or -2 in case of different errors.
A. -1 is a case of unsuccessuful connection to guest agent.
B. -2 is a case of destoyed domain during connection attempt.

All qemuConnectAgent callers handle the first error the same way
so let's move this logic into qemuConnectAgent itself. Patched
function returns 0 in case A and -1 in case B.
      851ae08e
  29. 02 11月, 2016 1 次提交
  31. 12 10月, 2016 2 次提交
  33. 26 9月, 2016 3 次提交
  35. 21 9月, 2016 1 次提交
    • J
      qemu: Ignore graphics cookie if port == 0 · 2e164b45
      由 Jiri Denemark 提交于 
      Old libvirt represents

    <graphics type='spice'>
      <listen type='none'/>
    </graphics>

as

    <graphics type='spice' autoport='no'/>

In this mode, QEMU doesn't listen for SPICE connection anywhere and
clients have to use virDomainOpenGraphics* APIs to attach to the domain.
That is, the client has to run on the same host where the domains runs
and it's impossible to tell the client to reconnect to the destination
QEMU during migration (unless there is some kind of proxy on the host).

While current libvirt correctly ignores such graphics devices when
creating graphics migration cookie, old libvirt just sends

    <graphics type='spice' port='0' listen='0.0.0.0' tlsPort='-1'/>

in the cookie. After seeing this cookie, we happily would call
client_migrate_info QMP command and wait for SPICE_MIGRATE_COMPLETED
event, which is quite pointless since the doesn't know where to connecti
anyway. We should just ignore such cookies.

https://bugzilla.redhat.com/show_bug.cgi?id=1376083Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      2e164b45
  37. 12 9月, 2016 1 次提交
    • J
      qemu: Don't use query-migrate on destination · 56258a38
      由 Jiri Denemark 提交于 
      When migration fails, we need to poke QEMU monitor to check for a reason
of the failure. We did this using query-migrate QMP command, which is
not supposed to return any meaningful result on the destination side.
Thus if the monitor was still functional when we detected the migration
failure, parsing the answer from query-migrate always failed with the
following error message:

    "info migration reply was missing return status"

This irrelevant message was then used as the reason for the migration
failure replacing any message we might have had.

Let's use harmless query-status for poking the monitor to make sure we
only get an error if the monitor connection is broken.

https://bugzilla.redhat.com/show_bug.cgi?id=1374613Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      56258a38
  39. 09 9月, 2016 1 次提交
  41. 25 8月, 2016 1 次提交
    • P
      qemu: migration: Prepare for non-contiguous vcpu configurations · 48e3d428
      由 Peter Krempa 提交于 
      Introduce a new migration cookie flag that will be used for any
configurations that are not compatible with libvirt that would not
support the specific vcpu hotplug approach. This will make sure that old
libvirt does not fail to reproduce the configuration correctly.
      48e3d428
  43. 22 8月, 2016 1 次提交
  45. 02 8月, 2016 2 次提交
  47. 18 7月, 2016 1 次提交
  49. 08 7月, 2016 1 次提交
  51. 30 6月, 2016 1 次提交