1. 21 10月, 2019 2 次提交
  2. 15 10月, 2019 1 次提交
  3. 08 10月, 2019 1 次提交
  4. 07 9月, 2019 1 次提交
  5. 09 8月, 2019 1 次提交
  6. 15 7月, 2019 1 次提交
  7. 11 7月, 2019 1 次提交
    • D
      bhyve: acquire a pidfile in the driver root directory · dbfdbd9a
      Daniel P. Berrangé 提交于
      When we allow multiple instances of the driver for the same user
      account, using a separate root directory, we need to ensure mutual
      exclusion. Use a pidfile to guarantee this.
      
      In privileged libvirtd this ends up locking
      
         /var/run/libvirt/bhyve/driver.pid
      
      In unprivileged libvirtd this ends up locking
      
        /run/user/$UID/libvirt/bhyve/run/driver.pid
      
      NB, the latter can vary depending on $XDG_RUNTIME_DIR
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      dbfdbd9a
  8. 09 7月, 2019 2 次提交
  9. 06 3月, 2019 1 次提交
  10. 20 2月, 2019 1 次提交
    • 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
  11. 17 12月, 2018 1 次提交
    • D
      qemu: use line breaks in command line args written to log · 07c9d660
      Daniel P. Berrangé 提交于
      The QEMU command line arguments are very long and currently all written
      on a single line to /var/log/libvirt/qemu/$GUEST.log. This introduces
      logic to add line breaks after every env variable and "-" optional
      argument, and every positional argument. This will create a clearer log
      file, which will in turn present better in bug reports when people cut +
      paste from the log into a bug comment.
      
      An example log file entry now looks like this:
      
        2018-12-14 12:57:03.677+0000: starting up libvirt version: 5.0.0, qemu version: 3.0.0qemu-3.0.0-1.fc29, kernel: 4.19.5-300.fc29.x86_64, hostname: localhost.localdomain
        LC_ALL=C \
        PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin \
        HOME=/home/berrange \
        USER=berrange \
        LOGNAME=berrange \
        QEMU_AUDIO_DRV=none \
        /usr/bin/qemu-system-ppc64 \
        -name guest=guest,debug-threads=on \
        -S \
        -object secret,id=masterKey0,format=raw,file=/home/berrange/.config/libvirt/qemu/lib/domain-33-guest/master-key.aes \
        -machine pseries-2.10,accel=tcg,usb=off,dump-guest-core=off \
        -m 1024 \
        -realtime mlock=off \
        -smp 1,sockets=1,cores=1,threads=1 \
        -uuid c8a74977-ab18-41d0-ae3b-4041c7fffbcd \
        -display none \
        -no-user-config \
        -nodefaults \
        -chardev socket,id=charmonitor,fd=23,server,nowait \
        -mon chardev=charmonitor,id=monitor,mode=control \
        -rtc base=utc \
        -no-shutdown \
        -boot strict=on \
        -device qemu-xhci,id=usb,bus=pci.0,addr=0x1 \
        -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x2 \
        -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
        -msg timestamp=on
        2018-12-14 12:57:03.730+0000: shutting down, reason=failed
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      07c9d660
  12. 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
  13. 17 9月, 2018 2 次提交
  14. 12 6月, 2018 1 次提交
  15. 28 5月, 2018 3 次提交
  16. 14 5月, 2018 1 次提交
  17. 04 5月, 2018 1 次提交
    • 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
  18. 23 4月, 2018 2 次提交
  19. 12 4月, 2018 5 次提交
  20. 11 4月, 2018 1 次提交
    • J
      bhyve: Use virDomainObjListFindBy{UUID|ID}Ref · f52d0d42
      John Ferlan 提交于
      For bhyveDomObjFromDomain, bhyveDomainLookupByUUID, and
      bhyveDomainLookupByID let's return a locked and referenced
      @vm object so that callers can then use the common and more
      consistent virDomainObjEndAPI in order to handle cleanup rather
      than needing to know that the returned object is locked and
      calling virObjectUnlock.
      
      The LookupByName already returns the ref counted and locked object,
      so this will make things more consistent.
      
      For bhyveDomainUndefine and bhyveDomainDestroy since the
      virDomainObjListRemove will return an unlocked object, we need to
      relock before making the EndAPI call.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      f52d0d42
  21. 22 2月, 2018 2 次提交
  22. 09 11月, 2017 1 次提交
  23. 19 10月, 2017 1 次提交
  24. 21 9月, 2017 1 次提交
    • J
      cpu_conf: Drop updateCPU from virCPUDefFormat · 4fd179f5
      Jiri Denemark 提交于
      In the past we updated host-model CPUs with host CPU data by adding a
      model and features, but keeping the host-model mode. And since the CPU
      model is not normally formatted for host-model CPU defs, we had to pass
      the updateCPU flag to the formatting code to be able to properly output
      updated host-model CPUs. Libvirt doesn't do this anymore, host-model
      CPUs are turned into custom mode CPUs once updated with host CPU data
      and thus there's no reason for keeping the hacks inside CPU XML
      formatters.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      4fd179f5
  25. 18 9月, 2017 1 次提交
  26. 06 8月, 2017 1 次提交
  27. 25 6月, 2017 1 次提交
    • J
      events: Avoid double free possibility on remote call failure · 2065499b
      John Ferlan 提交于
      If a remote call fails during event registration (more than likely from
      a network failure or remote libvirtd restart timed just right), then when
      calling the virObjectEventStateDeregisterID we don't want to call the
      registered @freecb function because that breaks our contract that we
      would only call it after succesfully returning.  If the @freecb routine
      were called, it could result in a double free from properly coded
      applications that free their opaque data on failure to register, as seen
      in the following details:
      
          Program terminated with signal 6, Aborted.
          #0  0x00007fc45cba15d7 in raise
          #1  0x00007fc45cba2cc8 in abort
          #2  0x00007fc45cbe12f7 in __libc_message
          #3  0x00007fc45cbe86d3 in _int_free
          #4  0x00007fc45d8d292c in PyDict_Fini
          #5  0x00007fc45d94f46a in Py_Finalize
          #6  0x00007fc45d960735 in Py_Main
          #7  0x00007fc45cb8daf5 in __libc_start_main
          #8  0x0000000000400721 in _start
      
      The double dereference of 'pyobj_cbData' is triggered in the following way:
      
          (1) libvirt_virConnectDomainEventRegisterAny is invoked.
          (2) the event is successfully added to the event callback list
              (virDomainEventStateRegisterClient in
              remoteConnectDomainEventRegisterAny returns 1 which means ok).
          (3) when function remoteConnectDomainEventRegisterAny is hit,
              network connection disconnected coincidently (or libvirtd is
              restarted) in the context of function 'call' then the connection
              is lost and the function 'call' failed, the branch
              virObjectEventStateDeregisterID is therefore taken.
          (4) 'pyobj_conn' is dereferenced the 1st time in
              libvirt_virConnectDomainEventFreeFunc.
          (5) 'pyobj_cbData' (refered to pyobj_conn) is dereferenced the
               2nd time in libvirt_virConnectDomainEventRegisterAny.
          (6) the double free error is triggered.
      
      Resolve this by adding a @doFreeCb boolean in order to avoid calling the
      freeCb in virObjectEventStateDeregisterID for any remote call failure in
      a remoteConnect*EventRegister* API. For remoteConnect*EventDeregister* calls,
      the passed value would be true indicating they should run the freecb if it
      exists; whereas, it's false for the remote call failure path.
      
      Patch based on the investigation and initial patch posted by
      fangying <fangying1@huawei.com>.
      2065499b
  28. 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
  29. 27 3月, 2017 1 次提交
    • M
      Remove src/nodeinfo · 26ae4e48
      Martin Kletzander 提交于
      There is no "node driver" as there was before, drivers have to do
      their own ACL checking anyway, so they all specify their functions and
      nodeinfo is basically just extending conf/capablities.  Hence moving
      the code to src/conf/ is the right way to go.
      
      Also that way we can de-duplicate some code that is in virsysfs and/or
      virhostcpu that got duplicated during the virhostcpu.c split.  And
      Some cleanup is done throughout the changes, like adding the vir*
      prefix etc.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      26ae4e48