1. 25 2月, 2019 9 次提交
  2. 24 2月, 2019 4 次提交
  3. 23 2月, 2019 2 次提交
  4. 22 2月, 2019 12 次提交
  5. 21 2月, 2019 3 次提交
  6. 20 2月, 2019 10 次提交
    • 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