Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 25 2月, 2019 4 次提交
  3. 24 2月, 2019 4 次提交
  5. 23 2月, 2019 2 次提交
  7. 22 2月, 2019 12 次提交
  9. 21 2月, 2019 3 次提交
  11. 20 2月, 2019 15 次提交
    • M
      testutils: Explicitly name virTestCompare*() arguments · 740aeb34
      由 Michal Privoznik 提交于 
      Currently, some arguments are called strcontent and strsrc, or
content and src or some other combination. This makes it
impossible to see at the first glance what argument is supposed
to represent 'expected' value and which one represents 'actual'
value. Rename the arguments to make it obvious.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      740aeb34
    • M
      virTestCompareToULL: Rename local variables · 9de317d0
      由 Michal Privoznik 提交于 
      The current naming makes it hard for me to see which holds the
expected value and which holds the actual value. Rename them to
make it obvious.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      9de317d0
    • M
      virTestCompareToULL: Use VIR_AUTOFREE() · 86d1f086
      由 Michal Privoznik 提交于 
      In order to save a few lines of code, and also since it's hype
let's use VIR_AUTOFREE() for the two strings we allocate there.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      86d1f086
    • A
      iohelper: Remove remaining newlines from error messages · 939f2542
      由 Andrea Bolognani 提交于 
      The iohelper is an internal program that's only supposed to
be called by libvirt, and whatever output it might produce
will ultimately be passed to virReportError() or similar.

Since we do not want strings passed to those functions to
contain newlines, we can simply not output them in the first
place.

This is what happens in pretty much all cases already, but
in a couple instances newlines have managed to slip in.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>
      939f2542
    • E
      snapshot: Define explicit flags for snapshot xml · a27031c4
      由 Eric Blake 提交于 
      Commit f609cb85 (0.9.5) introduced virDomainSnapshotGetXMLDesc()'s use
of @flags as a subset of virDomainXMLFlags, documenting that 2 of the
3 flags defined at the time would never be valid.  Later, commit
28f8dfdc (1.0.0) introduced a new flag, VIR_DOMAIN_XML_MIGRATABLE, but
did not adjust the snapshot documentation to declare it as invalid.
However, since the flag is not accepted as valid by any of the
drivers (remote is just passthrough; esx and vbox don't support flags;
qemu, test, and vz only support VIR_DOMAIN_XML_SECURE), and it is
unlikely that the domain state saved off during a snapshot creation
needs to be migration-friendly (as the snapshot is not the source of
a migration), it is easier to just define an explicit set of supported
flags directly related to the snapshot API rather than trying to
borrow from domain API, and risking confusion if even more domain
flags are added later (in fact, I have an upcoming patch that plans to
add a new flag to virDomainGetXMLDesc that makes no sense for
snapshots).

There is no API or ABI impact (since we purposefully used unsigned int
rather than an enum type in public API, and since the new flag name
carries the same value as the reused name).
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      a27031c4
    • E
      domain: Define explicit flags for saved image xml · 12a51f37
      由 Eric Blake 提交于 
      Commit d2a929d4 (0.9.4) defined virDomainSaveImageGetXMLDesc()'s use
of @flags as a subset of virDomainXMLFlags, documenting that 2 of the
3 flags defined at the time would never be valid.  Later, commit
28f8dfdc (1.0.0) introduced a new flag, VIR_DOMAIN_XML_MIGRATABLE, but
did not adjust the save image documentation to declare it as invalid.
Later, commit a67e3872 (3.7.0) blindly copied and pasted the same text
into virDomainManagedSaveGetXMLDesc.

However, since the flag is not accepted as valid by any of the
drivers (remote is just passthrough; and qemu is the only supporting
driver for either API, with support for just VIR_DOMAIN_XML_SECURE),
it is easier to just define an explicit set of supported flags
directly related to the save image API rather than trying to borrow
from live domain API, and risking confusion if even more domain flags
are added later (in fact, I have an upcoming patch that plans to add
a new flag to virDomainGetXMLDesc that makes no sense for saved
images).  We may someday decide that saved images need to support the
_MIGRATABLE flag, as it is possible to load a saved image with a
different version of libvirt than the one that created it, but that
can be a separate patch if it is ever needed.  Meanwhile, it DOES make
sense to reuse the same flags for SaveImage and for ManagedSave (since
ManagedSave is really just sugar for creating a normal SaveImage in a
location controlled by libvirt instead of by the user).

There is no API or ABI impact (since we purposefully used unsigned int
rather than an enum type in public API, and since the new flag name
carries the same value as the old reused name).
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      12a51f37
    • E
      qemu: Use correct domain xml flag · 022eeddf
      由 Eric Blake 提交于 
      Although VIR_DOMAIN_DEF_FORMAT_INACTIVE and VIR_DOMAIN_XML_INACTIVE
happen to have the same value (1<<1), they come from different enums;
and it is nicer to reason about a 'flags' variable if all uses of
that variable are compared against the same enum type.  Messed up in
commit 06f75ff2 (3.8.0).
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      022eeddf
    • E
      domain: Fix unknown flags diagnosis in virDomainGetXMLDesc · 27c8fd74
      由 Eric Blake 提交于 
      Many drivers had a comment that they did not validate the incoming
'flags' to virDomainGetXMLDesc() because they were relying on
virDomainDefFormat() to do it instead. This used to be the case
(at least since 461e0f1a and friends in 0.9.4 added unknown flag
checking in general), but regressed in commit 0ecd6851 (1.2.12),
when all of the drivers were changed to pass 'flags' through the
new helper virDomainDefFormatConvertXMLFlags(). Since this helper
silently ignores unknown flags, we need to implement flag checking
in each driver instead.

Annoyingly, this means that any new flag values added will silently
be ignored when targeting an older libvirt, rather than our usual
practice of loudly diagnosing an unsupported flag.  Add comments
in domain_conf.[ch] to remind us to be extra vigilant about the
impact when adding flags (a new flag to add data is safe if the
older server omitting the requested data doesn't break things in
the newer client; a new flag to suppress data rather than enhancing
the existing VIR_DOMAIN_XML_SECURE may form a data leak or even a
security hole).

In the qemu driver, there are multiple callers all funnelling to
qemuDomainDefFormatBufInternal(); many of them already validated
flags (and often only a subset of the full set of possible flags),
but for ease of maintenance, we can also check flags at the common
helper function.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      27c8fd74
    • C
      qemu_process: Enter QMP command mode when starting QEMU Process · 5b13da5c
      由 Chris Venteicher 提交于 
      qemuProcessQMPStart starts a QEMU process and monitor connection that
can be used by multiple functions possibly for multiple QMP commands.

The QMP exchange to exit capabilities negotiation mode and enter command
mode can only be performed once after the monitor connection is
established.

Move responsibility for entering QMP command mode into the
qemuProcessQMP code so multiple functions can issue QMP commands in
arbitrary orders.

This also simplifies the functions using the connection provided by
qemuProcessQMPStart to issue QMP commands.

Test code now needs to call qemuMonitorSetCapabilities to send the
message to switch to command mode because the test code does not use the
qemuProcessQMP command that internally calls qemuMonitorSetCapabilities.
Signed-off-by: NChris Venteicher <cventeic@redhat.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      5b13da5c
    • C
      qemu_process: Use unique directories for QMP processes · 5724dca1
      由 Chris Venteicher 提交于 
      Multiple QEMU processes for QMP commands can operate concurrently.

Use a unique directory under libDir for each QEMU process to avoid
pidfile and unix socket collision between processes.

The pid file name is changed from "capabilities.pidfile" to "qmp.pid"
because we no longer need to avoid a possible clash with a qemu domain
called "capabilities" now that the processes artifacts are stored in
their own unique temporary directories.

"Capabilities" was changed to "qmp" in the pid file name because these
processes are no longer specific to the capabilities usecase and are
more generic in terms of being used for any general purpose QMP message
exchanges with a QEMU process that is not associated with a domain.
Signed-off-by: NChris Venteicher <cventeic@redhat.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      5724dca1
    • J
      qemu_process: Hide qemuProcessQMPStop · f87eb560
      由 Jiri Denemark 提交于 
      Users qemuProcessQMP struct were always forced to call both
qemuProcessQMPStop and qemuProcessQMPFree when they are done with the
process. We can just call qemuProcessQMPStop from qemuProcessQMPFree and
let users call qemuProcessQMPFree only.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      f87eb560
    • C
      qemu_process: Document and cleanup qemuProcessQMPNew · e691b150
      由 Chris Venteicher 提交于 
      qemuProcessQMPNew is one of the public functions used to create and
manage a QEMU process for QMP command exchanges outside of domain
operations.

Add descriptive comment block, debug statement and make source
consistent with the cleanup / VIR_STEAL_PTR format used elsewhere.
Signed-off-by: NChris Venteicher <cventeic@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      e691b150
    • C
      qemu_process: Stop retaining monitor config in qemuProcessQMP · 095d36d0
      由 Chris Venteicher 提交于 
      The monitor config data is removed from the qemuProcessQMP struct.

The monitor config data can be initialized immediately before call to
qemuMonitorOpen and does not need to be maintained after the call
because qemuMonitorOpen copies any strings it needs.
Signed-off-by: NChris Venteicher <cventeic@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      095d36d0
    • C
      qemu_process: Setup paths within qemuProcessQMPInit · 9ab441c8
      由 Chris Venteicher 提交于 
      Move code for setting paths and prepping file system from
qemuProcessQMPNew to qemuProcessQMPInit.

This keeps qemuProcessQMPNew limited to data structures and path
initialization is done in qemuProcessQMPInit.

The patch is a non-functional, cut / paste change, however goto is now
"cleanup" rather than "error".
Signed-off-by: NChris Venteicher <cventeic@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      9ab441c8
    • C
      qemu_process: Store libDir in qemuProcessQMP struct · 9f25cdf7
      由 Chris Venteicher 提交于 
      Store libDir path in the qemuProcessQMP struct in anticipation of moving
path construction code into qemuProcessQMPInit function.
Signed-off-by: NChris Venteicher <cventeic@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
      9f25cdf7