1. 18 3月, 2019 9 次提交
  2. 16 3月, 2019 20 次提交
  3. 15 3月, 2019 11 次提交
    • E
      qemu: command: Override HOME variable for system QEMU · 75a91698
      Erik Skultety 提交于
      By default, qemu user's home dir points to '/' which shouldn't be used
      at all. We therefore pass the HOME variable from the current variable
      iff not running as SUID, which means that for systemd we never set it.
      This patch makes sure, that for system QEMU this is always set to
      libDir/<driver>, session mode is left untouched.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      75a91698
    • E
      qemu: command: Enforce setting XDG variables for system QEMU · 7e731374
      Erik Skultety 提交于
      For session mode, only XDG_CACHE_HOME is set, because we want to remain
      integrating with services in user session, but for system mode, this
      would have become reading/writing to '/' which carries the obvious issue
      with permissions (also, '/' is the wrong location in 99.9% cases anyway).
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      7e731374
    • E
      util: command: Introduce virCommandAddEnvXDG helper · 2d69af29
      Erik Skultety 提交于
      Some modules/libraries within QEMU could make use of the XDG_ vars when
      writing their data to the disk. Define the most common XDG variables
      and point them to the specific driver's libDir, i.e.
      
      XDG_CACHE_HOME -> /var/lib/libvirt/<driver>/.cache
      XDG_DATA_HOME -> /var/lib/libvirt/<driver>/.local/share
      XDG_CONFIG_HOME -> /var/lib/libvirt/<driver>/.config
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      2d69af29
    • P
      qemu: hotplug: Merge virtio and non-virtio disk unplug code · 0b7d544c
      Peter Krempa 提交于
      The functions do basically exactly the same thing modulo few checks.
      In case of virtio disks we check that the device is not multifunction as
      that can't be unplugged at once. In case of USB and SCSI disks we
      checked that no active block job is running.
      
      The check for running blockjobs should have also been done for virtio
      disks. By moving the multifunction check into the common function we fix
      this case and also simplify the code.
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      0b7d544c
    • P
    • P
      qemu: hotplug: Use typecasted enum in qemuDomainDetachDeviceDiskLive · afa15d78
      Peter Krempa 提交于
      Use the correct type in switch and populate the missing cases.
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      afa15d78
    • P
      qemu: hotplug: Remove 'ret' variable in qemuDomainDetachDeviceDiskLive · 70d06898
      Peter Krempa 提交于
      We don't have any cleanup section, we can return the value directly.
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      70d06898
    • E
      snapshot: More clarification about REDEFINE · a6a25d5c
      Eric Blake 提交于
      Based on recent list questions about the proposed addition of
      virDomainCheckpointCreateXML(REDEFINE), it is worth adding some
      clarification to the existing snapshot redefine documentation that is
      serving as the basis for checkpoints.
      
      Normal snapshot creation requires very few elements from the user XML
      (libvirt can pick sane defaults for items that are omitted, and many
      fields, including <domain>, are documented as readonly output fields
      ignored on input, produced by drivers that track it). But during
      REDEFINE, the API wants the complete XML produced by an earlier
      virDomainSnapshotGetXMLDesc; as the domain definition has likely
      changed since the snapshot was first created, libvirt is unable to
      recreate a <domain> sub-element that matches the original output
      representing the domain state at the time the snapshot was first
      created. In fact, reverting without a <domain> sub-element is risky
      enough that we had to add a FORCE flag for virDomainSnapshotRevert().
      In short, we only support omitting domain for qemu because of
      backwards-compatibility to snapshots created before 0.9.5 started
      capturing <domain>; even though there are other drivers like vbox that
      do not output <domain> because they have other reliable ways to
      revert.
      
      And based on the confusion caused when omitting <domain> from snapshot
      XML, the initial design for checkpoints in later patches will make
      <domain> a mandatory element during its REDEFINE.
      
      [Side note: the fact that <domain> can appear in <domainsnapshot> is a
      reason we cannot add a new API for a bulk listing or redefine of all
      snapshots of a single domain in one XML call (for example, a 1M
      <domain> XML * 16 snapshots explodes into 16M in a bulk form, which
      gets difficult to send over RPC). Perhaps we could add a flag to
      request that the <domain> sub-element be omitted on output, but such
      output is no longer suitable for sane REDEFINE input.]
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      a6a25d5c
    • E
      virobject: Improve documentation · 632ac8f8
      Eric Blake 提交于
      I had to inspect the code to learn whether a final virObjectUnref()
      calls ALL dispose callbacks in child-to-parent order (akin to C++
      destructors), or whether I manually had to call a parent-class dispose
      when writing a child class dispose method.  The answer is the
      former. (Thankfully, since VIR_FREE wipes out pointers for safety,
      even if I had guessed wrong, I probably would not have tripped over a
      double-free fault when the parent dispose ran for the second time).  I
      also had to read the code to learn if a dispose method was even
      mandatory (it is not, although getting NULL through VIR_CLASS_NEW
      requires a macro).  While at it, the VIR_CLASS_NEW macro requires that
      the virObject component at offset 0 be reached through the name
      'parent', not 'object'.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      632ac8f8
    • M
      qemu_hotplug: Fix a rare race condition when detaching a device twice · c2bc4191
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1623389
      
      If a device is detached twice from the same domain the following
      race condition may happen:
      
      1) The first DetachDevice() call will issue "device_del" on qemu
      monitor, but since the DEVICE_DELETED event did not arrive in
      time, the API ends claiming "Device detach request sent
      successfully".
      
      2) The second DetachDevice() therefore still find the device in
      the domain and thus proceeds to detaching it again. It calls
      EnterMonitor() and qemuMonitorSend() trying to issue "device_del"
      command again. This gets both domain lock and monitor lock
      released.
      
      3) At this point, qemu sends us the DEVICE_DELETED event which is
      going to be handled by the event loop which ends up calling
      qemuDomainSignalDeviceRemoval() to determine who is going to
      remove the device from domain definition. Whether it is the
      caller that marked the device for removal or whether it is going
      to be the event processing thread.
      
      4) Because the device was marked for removal,
      qemuDomainSignalDeviceRemoval() returns true, which means the
      event is to be processed by the thread that has marked the device
      for removal (and is currently still trying to issue "device_del"
      command)
      
      5) The thread finally issues the "device_del" command, which
      fails (obviously) and therefore it calls
      qemuDomainResetDeviceRemoval() to reset the device marking and
      quits immediately after, NOT removing any device from the domain
      definition.
      
      At this point, the device is still present in the domain
      definition but doesn't exist in qemu anymore. Worse, there is no
      way to remove it from the domain definition.
      
      Solution is to note down that we've seen the event and if the
      second "device_del" fails, not take it as a failure but carry on
      with the usual execution.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      ACKed-by: NPeter Krempa <pkrempa@redhat.com>
      c2bc4191
    • M
      qemuMonitorJSONDelDevice: Return -2 on DeviceNotFound error · 229a0358
      Michal Privoznik 提交于
      A caller might be interested in differentiating the cause for
      error, especially if DeviceNotFound error occurred.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      ACKed-by: NPeter Krempa <pkrempa@redhat.com>
      229a0358