1. 04 2月, 2019 1 次提交
  2. 14 12月, 2018 1 次提交
    • D
      Remove all Author(s): lines from source file headers · 60046283
      Daniel P. Berrangé 提交于
      In many files there are header comments that contain an Author:
      statement, supposedly reflecting who originally wrote the code.
      In a large collaborative project like libvirt, any non-trivial
      file will have been modified by a large number of different
      contributors. IOW, the Author: comments are quickly out of date,
      omitting people who have made significant contribitions.
      
      In some places Author: lines have been added despite the person
      merely being responsible for creating the file by moving existing
      code out of another file. IOW, the Author: lines give an incorrect
      record of authorship.
      
      With this all in mind, the comments are useless as a means to identify
      who to talk to about code in a particular file. Contributors will always
      be better off using 'git log' and 'git blame' if they need to  find the
      author of a particular bit of code.
      
      This commit thus deletes all Author: comments from the source and adds
      a rule to prevent them reappearing.
      
      The Copyright headers are similarly misleading and inaccurate, however,
      we cannot delete these as they have legal meaning, despite being largely
      inaccurate. In addition only the copyright holder is permitted to change
      their respective copyright statement.
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      60046283
  3. 05 12月, 2018 1 次提交
  4. 02 10月, 2018 1 次提交
    • J
      libxl: Fix possible object refcnt issue · 425b9f8a
      John Ferlan 提交于
      When libxlDomainMigrationDstPrepare adds the @args to an
      virNetSocketAddIOCallback using libxlMigrateDstReceive as
      the target of the virNetSocketIOFunc @func with the knowledge
      that the libxlMigrateDstReceive will virObjectUnref @args
      at the end thus not needing to Unref during normal processing
      for libxlDomainMigrationDstPrepare.
      
      However, Coverity believes there's an issue with this. The
      problem is there can be @nsocks virNetSocketAddIOCallback's
      added, but only one virObjectUnref. That means the first
      one done will Unref and the subsequent callers may not get
      the @args (or @opaque) as they expected. If there's only
      one socket returned from virNetSocketNewListenTCP, then sure
      that works. However, if it returned more than one there's
      going to be a problem.
      
      To resolve this, since we start with 1 reference from the
      virObjectNew for @args, we will add 1 reference for each
      time @args is used for virNetSocketAddIOCallback. Then
      since libxlDomainMigrationDstPrepare would be done with
      @args, move it's virObjectUnref from the error: label to
      the done: label (since error: falls through). That way
      once the last IOCallback is done, then @args will be freed.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
      425b9f8a
  5. 11 9月, 2018 5 次提交
  6. 13 6月, 2018 1 次提交
  7. 04 5月, 2018 3 次提交
    • J
      conf: Clean up object referencing for Add and Remove · b04629b6
      John Ferlan 提交于
      When adding a new object to the domain object list, there should
      have been 2 virObjectRef calls made one for each list into which
      the object was placed to match the 2 virObjectUnref calls that
      would occur during Remove as part of virHashRemoveEntry when
      virObjectFreeHashData is called when the element is removed from
      the hash table as set up in virDomainObjListNew.
      
      Some drivers (libxl, lxc, qemu, and vz) handled this inconsistency
      by calling virObjectRef upon successful return from virDomainObjListAdd
      in order to use virDomainObjEndAPI when done with the returned @vm.
      While others (bhyve, openvz, test, and vmware) handled this via only
      calling virObjectUnlock upon successful return from virDomainObjListAdd.
      
      This patch will "unify" the approach to use virDomainObjEndAPI
      for any @vm successfully returned from virDomainObjListAdd.
      
      Because list removal is so tightly coupled with list addition,
      this patch fixes the list removal algorithm to return the object
      as entered - "locked and reffed".  This way, the callers can then
      decide how to uniformly handle add/remove success and failure.
      This removes the onus on the caller to "specially handle" the
      @vm during removal processing.
      
      The Add/Remove logic allows for some logic simplification such
      as in libxl where we can Remove the @vm directly rather than
      needing to set a @remove_dom boolean and removing after the
      libxlDomainObjEndJob completes as the @vm is locked/reffed.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      b04629b6
    • J
      libxl: Add refcnt for args->conn during migration · faa148bc
      John Ferlan 提交于
      Since the @dconn reference via args->conn will be used via a thread
      or callback, let's make sure memory associated with it isn't free'd
      unexpectedly before we use it. The Unref will be done when the object
      is Dispose'd.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      faa148bc
    • J
      libxl: Add refcnt for args->vm during migration · 8369ddfd
      John Ferlan 提交于
      When adding the @vm to the @args for usage during a thread or
      callback, let's add the reference to it at the time of adding to
      ensure nothing else deletes it. The corresponding Unref is then
      added to the Dispose function.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      8369ddfd
  8. 18 4月, 2018 1 次提交
    • M
      virobject: Introduce VIR_CLASS_NEW() macro · 10f94828
      Michal Privoznik 提交于
      So far we are repeating the following lines over and over:
      
        if (!(virSomeObjectClass = virClassNew(virClassForObject(),
                                   "virSomeObject",
                                   sizeof(virSomeObject),
                                   virSomeObjectDispose)))
            return -1;
      
      While this works, it is impossible to do some checking. Firstly,
      the class name (the 2nd argument) doesn't match the name in the
      code in all cases (the 3rd argument). Secondly, the current style
      is needlessly verbose. This commit turns example into following:
      
        if (!(VIR_CLASS_NEW(virSomeObject,
                            virClassForObject)))
            return -1;
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      10f94828
  9. 22 3月, 2018 4 次提交
  10. 17 3月, 2018 3 次提交
    • J
      libxl: MigratePrepare: use standard begin and end API pattern · 60b3fcd9
      Jim Fehlig 提交于
      libxlDomainMigrationPrepare adds the incoming domain def to the list
      of domains via virDomainObjListAdd, but never adds its own ref to the
      returned virDomainObj as other callers of virDomainObjListAdd do.
      libxlDomainMigrationPrepareTunnel3 suffers the same discrepancy.
      
      Change both to add a ref to the virDomainObj after a successful
      virDomainObjListAdd, similar to other callers. This ensures a consistent
      pattern throughout the drivers and allows using the virDomainObjEndAPI
      function for cleanup.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      60b3fcd9
    • J
      libxl: MigrateConfirm: Dont unlock virDomainObj in helper function · 99486799
      Jim Fehlig 提交于
      The libxlDomainMigrateConfirm3Params API locks and ref counts the associated
      virDomainObj but relies on the helper function libxlDomainMigrationConfirm
      to unlock the object. Unref'ing the object is not done in either function.
      libxlDomainMigrationConfirm is also used by libxlDomainMigratePerform3Params
      for p2p migration, but in that case the lock/ref and unref/unlock are
      properly handled in the API entry point.
      
      Remove the unlock from libxlDomainMigrationConfirm and adjust
      libxlDomainMigrateConfirm3Params to properly unref/unlock the virDomainObj
      on success and error paths.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      99486799
    • J
      libxl: MigrateBegin: Dont call EndAPI in helper function · 64370c4b
      Jim Fehlig 提交于
      The libxlDomainMigrateBegin3Params API locks and ref counts the associated
      virDomainObj but relies on the helper function libxlDomainMigrationBegin
      to unref/unlock the object. libxlDomainMigrationBegin is also used by
      libxlDomainMigratePerform3Params for p2p migration, but in that case the
      lock/ref and unref/unlock are properly handled in the API entry point. So
      p2p migrations suffer a double unref/unlock in the Perform API.
      
      Remove the unref/unlock (virDomainObjEndAPI) from libxlDomainMigrationBegin
      and adjust libxlDomainMigrateBegin3Params to properly unref/unlock
      the virDomainObj on success and error paths.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      64370c4b
  11. 22 2月, 2018 1 次提交
  12. 26 1月, 2018 1 次提交
    • J
      libxl: resume lock process after failed migration · 0c710a37
      Jim Fehlig 提交于
      During migration, the lock process is paused in the perform phase
      but not resumed if there is a subsequent failure, leaving the locked
      resource unprotected.
      
      The perform phase itself can fail, in which case the lock process
      should be resumed before returning from perform. The finish phase
      could also fail on the destination host, in which case the migration
      is canceled in the confirm phase and the VM is resumed. The lock
      process needs to be resumed there as well.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      0c710a37
  13. 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
  14. 27 3月, 2017 1 次提交
  15. 16 3月, 2017 1 次提交
  16. 17 2月, 2017 1 次提交
  17. 16 2月, 2017 2 次提交
    • B
      libxl: add tunnelled migration support · 6a95edf9
      Bob Liu 提交于
      Tunnelled migration doesn't require any extra network connections
      beside the libvirt daemon.  It's capable of strong encryption and the
      default option of openstack-nova.
      
      This patch adds the tunnelled migration(Tunnel3params) support to
      libxl.  On the source side, the data flow is:
      
       * libxlDoMigrateSend() -> pipe libxlTunnel3MigrationFunc() polls pipe
       * out and then write to dest stream.
      
      While on the destination side:
       * Stream -> pipe -> 'recvfd of libxlDomainStartRestore'
      
      The usage is the same as p2p migration, execpt adding one extra
      '--tunnelled' to the libvirt p2p migration command.
      Signed-off-by: NBob Liu <bob.liu@oracle.com>
      Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
      6a95edf9
    • J
      libxl: refactor libxlDomainMigrationPrepare · d2100f2b
      Joao Martins 提交于
      The newly introduced function libxlDomainMigrationPrepareAny
      will be shared between P2P and tunnelled variations.
      Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
      d2100f2b
  18. 25 10月, 2016 1 次提交
    • J
      libxl: fix leaking of allocated migration ports · f830674b
      Jim Fehlig 提交于
      Although the migration port is immediately released in the
      finish phase of migration, it was never set in the domain
      private object when allocated in the prepare phase. So
      libxlDomainMigrationFinish() always released a 0-initialized
      migrationPort, leaking any allocated port. After enough
      migrations to exhaust the migration port pool, migration would
      fail with
      
      error: internal error: Unable to find an unused port in range
             'migration' (49152-49216)
      
      Fix it by setting libxlDomainObjPrivate->migrationPort to the
      port allocated in the prepare phase. While at it, also fix
      leaking an allocated port if the prepare phase fails.
      f830674b
  19. 26 9月, 2016 1 次提交
  20. 22 9月, 2016 1 次提交
    • J
      libxl: support VIR_MIGRATE_PERSIST_DEST migration flag · 1fc90ae9
      Jim Fehlig 提交于
      By default, virt-manager (and likely other libvirt-based apps) sets
      the VIR_MIGRATE_PERSIST_DEST flag when invoking the migrate API, which
      fails in a Xen setup since the libxl driver does not support the flag.
      
      Persisting a domain is a trivial task in the grand scheme of migration,
      so be nice to libvirt apps and add support for VIR_MIGRATE_PERSIST_DEST
      in the libxl driver.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      1fc90ae9
  21. 04 8月, 2016 1 次提交
  22. 02 8月, 2016 1 次提交
  23. 13 6月, 2016 1 次提交
    • W
      libxl: fix vm lock overwritten bug · 9ac94507
      Wang Yufei 提交于
      In libxl driver we do virObjectRef in libxlDomainObjBeginJob,
      If virCondWaitUntil failed, it goes to error, do virObjectUnref,
      There's a chance that someone undefine the vm at the same time,
      and refs unref to zero, vm is freed in libxlDomainObjBeginJob.
      But the vm outside function is not Null, we do virObjectUnlock(vm).
      That's how we overwrite the vm memory after it's freed. I fix it.
      Signed-off-by: NWang Yufei <james.wangyufei@huawei.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      9ac94507
  24. 07 6月, 2016 1 次提交
    • P
      conf: Add infrastructure for adding configuration validation · b394af16
      Peter Krempa 提交于
      Until now we weren't able to add checks that would reject configuration
      once accepted by the parser. This patch adds a new callback and
      infrastructure to add such checks. In this patch all the places where
      rejecting a now-invalid configuration wouldn't be a good idea are marked
      with a new parser flag.
      b394af16
  25. 17 5月, 2016 1 次提交
    • J
      libxl: Free migration cookie · 1222a303
      John Ferlan 提交于
      Commit id 'f9edcfa4' added cookie manipulation for libxl; however, some
      cookie crumb cleanup was missed. Found by Coverity.
      
      In libxlDomainMigrationBegin, the cookie is allocated and baked; however,
      the mig ingredients weren't cleaned up.
      
      In libxlDomainMigrationPrepare, when the 'mig' cookie is added to the
      args, set the 'mig = NULL'; otherwise, other failure paths between when
      the code ate the cookie data and when it was added to args would fail
      to clean up the crumbs.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      1222a303
  26. 11 5月, 2016 2 次提交
    • J
      libxl: support migration stream V2 in migration · f9edcfa4
      Jim Fehlig 提交于
      Similar to "support Xen migration stream V2 in save/restore",
      add support for indicating the migration stream version in
      the migration code. To accomplish this, add a minimal migration
      cookie in the libxl driver that is passed between source and
      destination hosts. Initially, the cookie is only used in
      the Begin and Prepare phases of migration to communicate the
      version of the migration stream produced by the source.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      f9edcfa4
    • J
      libxl: support Xen migration stream V2 in save/restore · 5325123d
      Jim Fehlig 提交于
      Xen 4.6 introduced a new migration stream commonly referred to as
      "migration V2". Xen 4.6 and newer always produce this new stream,
      whereas Xen 4.5 and older always produce the legacy stream.
      Support for migration stream V2 can be detected at build time with
      LIBXL_HAVE_SRM_V2 from libxl.h. The legacy and V2 streams are not
      compatible, but a V2 host can accept and convert a legacy stream.
      
      Commit e7440656 changed the libxl driver to use the lowest libxl
      API version possible (version 0x040200) to ensure the driver
      builds against older Xen releases. The old 4.2 restore API does
      not support specifying a stream version and assumes a legacy
      stream, even if the incoming stream is migration V2. Thinking it
      has been given a legacy stream, libxl will fail to convert an
      incoming stream that is already V2, which causes the entire
      restore operation to fail. Xen's libvirt-related OSSTest has been
      failing since commit e7440656 landed in libvirt.git master. One
      of the more recent failures can be seen here
      
      http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00071.html
      
      This patch changes the call to libxl_domain_create_restore() to
      include the stream version if LIBXL_HAVE_SRM_V2 is defined. The
      version field of the libxlSavefileHeader struct is also updated
      to '2' when LIBXL_HAVE_SRM_V2 is defined, ensuring the stream
      version in the header matches the actual stream version produced
      by Xen. Along with bumping the libxl API requirement to 0x040400,
      this patch fixes save/restore on a migration V2 Xen host.
      
      Oddly, migration has never used the libxlSavefileHeader. It
      handles passing configuration in the Begin and Prepare phases,
      and then calls libxl directly to transfer domain state/memory
      in the Perform phase. A subsequent patch will add stream
      version handling in the Begin and Prepare phase handshaking,
      which will fix the migration related OSSTest failures.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      5325123d
  27. 10 2月, 2016 1 次提交
    • J
      libxl: keepalive messages support · 5194eb95
      Joao Martins 提交于
      This patch introduces keep alive messages support for P2P migration
      and it adds two new configuration entries namely 'keepalive_interval'
      'keepalive_count' to control it. Behavior of these entries is the
      same as qemu driver thus the description is copied from there
      with just a few simplifications.
      Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
      5194eb95