1. 02 5月, 2016 1 次提交
    • J
      qemu: Introduce qemuDomainSecretPrepare and Destroy · 40d8e2ba
      John Ferlan 提交于
      Rather than needing to pass the conn parameter to various command
      line building API's, add qemuDomainSecretPrepare just prior to the
      qemuProcessLaunch which calls qemuBuilCommandLine. The function
      must be called after qemuProcessPrepareHost since it's expected
      to eventually need the domain masterKey generated during the prepare
      host call. Additionally, future patches may require device aliases
      (assigned during the prepare domain call) in order to associate
      the secret objects.
      
      The qemuDomainSecretDestroy is called after the qemuProcessLaunch
      finishes in order to clear and free memory used by the secrets
      that were recently prepared, so they are not kept around in memory
      too long.
      
      Placing the setup here is beneficial for future patches which will
      need the domain masterKey in order to generate an encrypted secret
      along with an initialization vector to be saved and passed (since
      the masterKey shouldn't be passed around).
      
      Finally, since the secret is not added during command line build,
      the hotplug code will need to get the secret into the private disk data.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      40d8e2ba
  2. 13 4月, 2016 1 次提交
  3. 23 3月, 2015 2 次提交
  4. 10 2月, 2015 2 次提交
  5. 27 1月, 2015 1 次提交
  6. 19 1月, 2015 1 次提交
  7. 15 12月, 2014 1 次提交
  8. 06 10月, 2014 1 次提交
  9. 20 8月, 2014 2 次提交
  10. 14 8月, 2014 1 次提交
  11. 24 7月, 2014 1 次提交
  12. 25 6月, 2014 1 次提交
    • J
      qemu: enum cleanups in "src/qemu/*" · aa990efe
      Julio Faracco 提交于
      As we are doing with the enum structures, a cleanup in "src/qemu/"
      directory was done now. All the enums that were defined in the
      header files were converted to typedefs in this directory. This
      patch includes all the adjustments to remove conflicts when you do
      this kind of change. "Enum-to-typedef"'s conversions were made in
      "src/qemu/qemu_{capabilities, domain, migration, hotplug}.h".
      Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
      aa990efe
  13. 02 6月, 2014 1 次提交
    • J
      qemu: Finish device removal in the original thread · 4670f1dd
      Jiri Denemark 提交于
      If QEMU supports DEVICE_DELETED event, we always call
      qemuDomainRemoveDevice from the event handler. However, we will need to
      push this call away from the main event loop and begin a job for it (see
      the following commit), we need to make sure the device is fully removed
      by the original thread (and within its existing job) in case the
      DEVICE_DELETED event arrives before qemuDomainWaitForDeviceRemoval times
      out.
      
      Without this patch, device removals would be guaranteed to never finish
      before the timeout because the could would be blocked by the original
      job being still active.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      4670f1dd
  14. 06 12月, 2013 1 次提交
  15. 21 11月, 2013 1 次提交
  16. 26 8月, 2013 2 次提交
  17. 18 7月, 2013 1 次提交
  18. 17 7月, 2013 1 次提交
  19. 16 7月, 2013 2 次提交
    • M
      qemu: Implement chardev hotplug on live level · 24b08219
      Michal Privoznik 提交于
      Since previous patches has prepared everything for us, we may now
      implement live hotplug of a character device.
      24b08219
    • M
      qemu: Implement chardev hotplug on config level · 75f0fd51
      Michal Privoznik 提交于
      There are two levels on which a device may be hotplugged: config
      and live. The config level requires just an insert or remove from
      internal domain definition structure, which is exactly what this
      patch does. There is currently no implementation for a chardev
      update action, as there's not much to be updated. But more
      importantly, the only thing that can be updated is path or socket
      address by which chardevs are distinguished. So the update action
      is currently not supported.
      75f0fd51
  20. 14 3月, 2013 1 次提交
  21. 21 2月, 2013 1 次提交
    • O
      qemu: Remove the shared disk entry if the operation is ejecting or updating · d0172d2b
      Osier Yang 提交于
      For both AttachDevice and UpdateDevice APIs, if the disk device
      is 'cdrom' or 'floppy', the operations could be ejecting, updating,
      and inserting. For either ejecting or updating, the shared disk
      entry of the original disk src has to be removed, because it's
      not useful anymore.
      
      And since the original disk def will be changed, new disk def passed
      as argument will be free'ed in qemuDomainChangeEjectableMedia, so
      we need to copy the orignal disk def before
      qemuDomainChangeEjectableMedia, to use it for qemuRemoveSharedDisk.
      d0172d2b
  22. 29 11月, 2012 1 次提交
  23. 15 10月, 2012 1 次提交
    • L
      qemu: reorganize qemuDomainChangeNet and qemuDomainChangeNetBridge · 6bde0a1a
      Laine Stump 提交于
      This patch resolves:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=805071
      
      to the extent that it can be resolved with current qemu functionality.
      It attempts to detect as many situations as possible when the simple
      operation of disconnecting an existing tap device from one bridge and
      attaching it to another will satisfy the change requested in
      virDomainUpdateDeviceFlags() for a network device. Before this patch,
      that situation could only be detected if the pre-change interface
      *and* the post-change interface definition were both "type='bridge'".
      After this patch, it can also be detected if the before or after
      interfaces are any combination of type='bridge' and type='network'
      (the networks can be <forward mode='nat|route|bridge'>, as long as
      they use a Linux host bridge and not macvtap connections).
      
      This extra effort is especially useful since the recent discovery that
      a netdev_del+netdev_add combo (to reconnect the network device with
      completely different hostside configuration) doesn't work properly
      with current qemu (1.2) unless it is accompanied by the matching
      device_del+device_add - see this mailing list message for details:
      
        http://lists.nongnu.org/archive/html/qemu-devel/2012-10/msg02355.html
      
      (A slight modification of the patch referenced there has been prepared
      to apply on top of this patch, but won't be pushed until qemu can be
      made to work with it.)
      
      * qemuDomainChangeNet needs access to the virDomainDeviceDef that
      holds the new netdef (so that it can clear out the virDomainDeviceDef
      if it ends up using the NetDef to replace the original), so the
      virDomainNetDefPtr arg is replaced with a virDomainDeviceDefPtr.
      
      * qemuDomainChangeNet previously checked for *some* changes to the
      interface config, but this check was by no means complete. It was also
      a bit disorganized.
      
      This refactoring of the code is (I believe) complete in its check of
      all NetDef attributes that might be changed, and either returns a
      failure (for changes that are simply impossible), or sets one of three
      flags:
      
        needLinkStateChange - if the device link state needs to go up/down
        needBridgeChange    - if everything else is the same, but it needs
                              to be connected to a difference linux host
                              bridge
        needReconnect       - if the entire host side of the device needs
                              to be torn down and reconstructed (currently
                              non-working, as mentioned above)
      
      Note that this function will refuse to make any change that requires
      the *guest* side of the device to be detached (e.g. changing the PCI
      address or mac address). Those would be disruptive enough to the guest
      that it's reasonable to require an explicit detach/attach sequence
      from the management application.
      
      * As mentioned above, qemuDomainChangeNet also does its best to
      understand when a simple change in attached bridge for the existing
      tap device will work vs. the need to completely tear down/reconstruct
      the host side of the device (including tap device).
      
      This patch *does not* implement the "reconnect" code anyway - there is
      a placeholder that turns that into an error. Rather, the purpose of
      this patch is to replicate existing behavior with code that is ready
      to have that functionality plugged in in a later patch.
      
      * The expanded uses for qemuDomainChangeNetBridge meant that it needed
      to be enhanced as well - it no longer replaces the original brname
      string in olddev with the new brname; instead, it relies on the
      caller to replace the *entire* olddev with newdev (since we've gone
      to great lengths to assure they are functionally identical other
      than the name of the bridge, this is now not only safe, but more
      correct). Additionally, qemuDomainNetChangeBridge can now set the
      bridge for type='network' interfaces as well as plain type='bridge'
      interfaces. (Note that I had to make this change simultaneous to the
      reorganization of qemuDomainChangeNet because the two are too
      closely intertwined to separate).
      6bde0a1a
  24. 21 9月, 2012 1 次提交
  25. 23 7月, 2012 1 次提交
    • O
      Desert the FSF address in copyright · f9ce7dad
      Osier Yang 提交于
      Per the FSF address could be changed from time to time, and GNU
      recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html)
      
        You should have received a copy of the GNU General Public License
        along with Foobar.  If not, see <http://www.gnu.org/licenses/>.
      
      This patch removes the explicit FSF address, and uses above instead
      (of course, with inserting 'Lesser' before 'General').
      
      Except a bunch of files for security driver, all others are changed
      automatically, the copyright for securify files are not complete,
      that's why to do it manually:
      
        src/security/security_selinux.h
        src/security/security_driver.h
        src/security/security_selinux.c
        src/security/security_apparmor.h
        src/security/security_apparmor.c
        src/security/security_driver.c
      f9ce7dad
  26. 03 4月, 2012 1 次提交
    • J
      qemu: Start nested job in qemuDomainCheckEjectableMedia · 66cab01a
      Jiri Denemark 提交于
      Originally, qemuDomainCheckEjectableMedia was entering monitor with qemu
      driver lock. Commit 2067e31b, which I
      made to fix that, revealed another issue we had (but didn't notice it
      since the driver was locked): we didn't set nested job when
      qemuDomainCheckEjectableMedia is called during migration. Thus the
      original fix I made was wrong.
      66cab01a
  27. 16 12月, 2011 1 次提交
    • M
      qemu: Don't drop hostdev config until security label restore · 13d5a6b8
      Michal Privoznik 提交于
      Currently, on device detach, we parse given XML, find the device
      in domain object, free it and try to restore security labels.
      However, in some cases (e.g. usb hostdev) parsed XML contains
      less information than freed device. In usb case it is bus & device
      IDs. These are needed during label restoring as a symlink into
      /dev/bus is generated from them. Therefore don't drop device
      configuration until security labels are restored.
      13d5a6b8
  28. 01 11月, 2011 1 次提交
  29. 29 9月, 2011 1 次提交
  30. 06 9月, 2011 1 次提交
    • P
      link-state: qemu: Add net intf modification to virUpdateDeviceFlags · e0a07bb1
      Peter Krempa 提交于
      This patch enables modifying network device configuration using the
      virUpdateDeviceFlags API method. Matching of devices is accomplished
      using MAC addresses.
      
      While updating live configuration of a running domain, the user is
      allowed only to change link state of the interface. Additional
      modifications may be added later. For now the code checks for
      unsupported changes and thereafter changes the link state, if
      applicable.
      
      When updating persistent configuration of guest's network interface the
      whole configuration (except for the MAC address) may be modified and
      is stored for the next startup.
      
      * src/qemu/qemu_driver.c   - Add dispatching of virUpdateDevice for
                                   network devices update (live/config)
      * src/qemu/qemu_hotplug.c  - add setting of initial link state on live
                                   device addition
                                 - add function to change network device
                                   configuration. By now it supports only
                                   changing of link state
      * src/qemu/qemu_hotplug.h  - Headers to above functions
      * src/qemu/qemu_process.c  - set link states before virtual machine
                                   start. Qemu does not support setting of
                                   this on the command line.
      e0a07bb1
  31. 02 9月, 2011 1 次提交
  32. 02 6月, 2011 1 次提交
    • D
      Allow leases to be hotpluged with QEMU guests · 30ffe7bc
      Daniel P. Berrange 提交于
      * src/conf/domain_conf.c, src/conf/domain_conf.h: APIs for
        inserting/finding/removing virDomainLeaseDefPtr instances
      * src/qemu/qemu_driver.c: Wire up hotplug/unplug for leases
      * src/qemu/qemu_hotplug.h, src/qemu/qemu_hotplug.c: Support
        for hotplug and unplug of leases
      30ffe7bc
  33. 05 5月, 2011 1 次提交
  34. 08 3月, 2011 1 次提交
  35. 24 2月, 2011 1 次提交