1. 04 4月, 2019 4 次提交
    • N
      qemu: Pass stop reason from qemuProcessStopCPUs to stop handler · 93c7d13e
      Nikolay Shirokovskiy 提交于
      Similar to commit [1] which saves and passes the running reason to
      the RESUME event handler, during qemuProcessStopCPUs let's save and pass
      the pause reason in the domain private data so that the STOP event
      handler can use it.
      
      [1] 5dab984e : qemu: Pass running reason to RESUME event handler
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      93c7d13e
    • M
      virNWFilterBindingObjListAddLocked: Produce better error message than 'Duplicate key' · b701e45b
      Michal Privoznik 提交于
      If there are two concurrent threads, one of which is removing an
      nwfilter from the list and the other is trying to add it back they
      may serialize in the following order:
      
      1) obj->removing is set and @obj is unlocked.
      2) The tread that's trying to add the nwfilter onto the list locks
         the list and tries to find, if the nwfilter already exists.
      3) Our lookup functions say it doesn't, so the thread proceeds to
         virHashAddEntry() which fails with 'Duplicate key' error.
      
      This is obviously not helpful error message at all.
      
      The problem lies in our lookup function
      (virNWFilterBindingObjListFindByPortDevLocked()) which return
      NULL even if the object is still on the list. They do this so
      that the object is not mistakenly looked up by some API. The fix
      consists of moving 'removing' check one level up and thus
      allowing virNWFilterBindingObjListAddLocked() to produce
      meaningful error message.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      b701e45b
    • M
      virDomainObjListAddLocked: Produce better error message than 'Duplicate key' · a5c71129
      Michal Privoznik 提交于
      If there are two concurrent threads, one of which is removing a
      domain from the list and the other is trying to add it back they
      may serialize in the following order:
      
      1) vm->removing is set and @vm is unlocked.
      2) The tread that's trying to add the domain onto the list locks
         the list and tries to find, if the domain already exists.
      3) Our lookup functions say it doesn't, so the thread proceeds to
         virHashAddEntry() which fails with 'Duplicate key' error.
      
      This is obviously not helpful error message at all.
      
      The problem lies in our lookup functions
      (virDomainObjListFindByUUIDLocked() and
      virDomainObjListFindByNameLocked()) which return NULL even if the
      object is still on the list. They do this so that the object is
      not mistakenly looked up by some driver. The fix consists of
      moving 'removing' check one level up and thus allowing
      virDomainObjListAddLocked() to produce meaningful error message.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      a5c71129
    • H
      virsh.pod: Improve native configuration format doc · fe34bf3a
      Han Han 提交于
      Add native guest format of BSD hypervisor and VMware/ESX. Quote native
      guest format of domxml-from-native for domxml-to-native.
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      Signed-off-by: NHan Han <hhan@redhat.com>
      fe34bf3a
  2. 03 4月, 2019 36 次提交