1. 07 9月, 2019 1 次提交
  2. 17 9月, 2018 1 次提交
  3. 10 4月, 2018 1 次提交
  4. 22 2月, 2018 3 次提交
  5. 18 10月, 2017 1 次提交
    • E
      maint: Replace tabs with spaces in all source files in repo · b08017ca
      Erik Skultety 提交于
      So we have a syntax-check rule to catch all tab indents but it naturally
      can't catch tab spacing, i.e. as a delimiter. This patch is a result of
      running 'vim -en +retab +wq'
      (using tabstop=8 softtabstop=4 shiftwidth=4 expandtab) on each file from
      a list generated by the following:
      find . -regextype gnu-awk \
               -regex ".*\.(rng|syms|html|s?[ch]|py|pl|php(\.code)?)(\.in)?" \
               | xargs git grep -lP "\t"
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      b08017ca
  6. 06 8月, 2017 1 次提交
  7. 12 3月, 2017 1 次提交
  8. 14 10月, 2016 1 次提交
  9. 05 5月, 2016 2 次提交
    • R
      bhyve: implement domainShutdown · 9e0bb1c8
      Roman Bogorodskiy 提交于
      Bhyve supports ACPI shutdown by issuing SIGTERM signal to a bhyve
      process.
      
      Add the bhyveDomainShutdown() function and virBhyveProcessShutdown()
      helper function that just sends SIGTERM to VM's bhyve process. If
      a guest supports ACPI shutdown then process will be terminated and
      this event will be noticed by the bhyve monitor code that will handle
      setting proper status and clean up VM's resources by calling
      virBhyveProcessStop().
      9e0bb1c8
    • R
      bhyve: drop virProcessKillPainfully() from destroy · c35c2fe7
      Roman Bogorodskiy 提交于
      Current implementation of domainDestroy for bhyve calls
      virProcessKillPainfully() for the bhyve process and then
      executes "bhyvectl --destroy".
      
      This is wrong for two reasons:
      
       * bhyvectl --destroy alone is sufficient because it terminates
         the process
       * virProcessKillPainfully() first sends SIGTERM and after few
         attempts sends SIGKILL. As SIGTERM triggers ACPI shutdown that
         we're not interested in, it creates an unwanted side effect in
         domainDestroy.
      
      Also, destroy monitor only after "bhyvectl --destroy" command succeeded
      to avoid a case when the command fails and domain remains running, but
      not being monitored anymore.
      c35c2fe7
  10. 06 2月, 2016 1 次提交
    • M
      bhyve: Fix the build · 5147f4f3
      Michal Privoznik 提交于
      After 1036ddad we use bhyveDriverGetCapabilities from other
      sources too, not only from bhyve_driver.c. However, the function
      was static so not properly expose to other files. In order to
      expose it, we need to move couple of #include-s too.
      Then, there has been a copy paste error in
      virBhyveProcessReconnect: s/privconn/data->driver/.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      5147f4f3
  11. 05 2月, 2016 1 次提交
  12. 17 11月, 2015 1 次提交
    • R
      bhyve: monitor: do not override domain's privateData · 89316b2c
      Roman Bogorodskiy 提交于
      Current monitor code overrides domain object's privateData, e.g.
      in virBhyveProcessStart():
      
        vm->privateData = bhyveMonitorOpen(vm, driver);
      
      where bhyveMonitorPtr() returns bhyveMonitorPtr.
      
      This is not right thing to do, so make bhyveMonitorPtr
      a part of the bhyveDomainObjPrivate struct and change related code
      accordingly.
      89316b2c
  13. 04 12月, 2014 1 次提交
  14. 13 11月, 2014 1 次提交
  15. 12 11月, 2014 1 次提交
    • C
      bhyve: Support /domain/bootloader configuration for non-FreeBSD guests. · 17722c16
      Conrad Meyer 提交于
      We still default to bhyveloader(1) if no explicit bootloader
      configuration is supplied in the domain.
      
      If the /domain/bootloader looks like grub-bhyve and the user doesn't
      supply /domain/bootloader_args, we make an intelligent guess and try
      chainloading the first partition on the disk (or a CD if one exists,
      under the assumption that for a VM a CD is likely an install source).
      
      Caveat: Assumes the HDD boots from the msdos1 partition. I think this is
      a pretty reasonable assumption for a VM. (DrvBhyve with Bhyveload
      already assumes that the first disk should be booted.)
      
      I've tested both HDD and CD boot and they seem to work.
      17722c16
  16. 16 9月, 2014 1 次提交
    • J
      Wire up the interface backend options · b20d39a5
      Ján Tomko 提交于
      Pass the user-specified tun path down when creating tap device
      when called from the qemu driver.
      
      Also honor the vhost device path specified by user.
      b20d39a5
  17. 20 8月, 2014 1 次提交
    • R
      bhyve: add volumes support · 6c2e7d0b
      Roman Bogorodskiy 提交于
      Update bhyveBuildDiskArgStr to support volumes:
      
       - Make virBhyveProcessBuildBhyveCmd and
         virBhyveProcessBuildLoadCmd take virConnectPtr as the
         first argument instead of bhyveConnPtr as virConnectPtr is
         needed for virStorageTranslateDiskSourcePool,
       - Add virStorageTranslateDiskSourcePool call to
         virBhyveProcessBuildBhyveCmd and
         virBhyveProcessBuildLoadCmd,
       - Allow disks of type VIR_STORAGE_TYPE_VOLUME
      6c2e7d0b
  18. 19 7月, 2014 1 次提交
    • R
      bhyve: reconnect to domains after libvirtd restart · 29e45ea1
      Roman Bogorodskiy 提交于
      Try to reconnect to the running domains after libvirtd restart. To
      achieve that, do:
      
       * Save domain state
        - Modify virBhyveProcessStart() to save domain state to the state
          dir
        - Modify virBhyveProcessStop() to cleanup the pidfile and the state
      
       * Detect if the state information loaded from the driver's state
         dir matches the actual state. Consider domain active if:
          - PID it points to exist
          - Process title of this PID matches the expected one with the
            domain name
      
         Otherwise, mark the domain as shut off.
      
      Note: earlier development bhyve versions before FreeBSD 10.0-RELEASE
      didn't set proctitle we expect, so the current code will not detect
      it. I don't plan adding support for this unless somebody requests
      this.
      29e45ea1
  19. 14 6月, 2014 2 次提交
    • R
      bhyve: silent destroy command errors on cleanup · f477f555
      Roman Bogorodskiy 提交于
      When virBhyveProcessStart() fails, it tries to unload
      a guest that could have been already loaded using
      bhyveload(8) to make sure not to leave it hanging in memory.
      
      However, we could fail before loading a VM into memory,
      so 'bhyvectl --destroy' command will fail and print
      an error message that looks confusing to users.
      
      So ignore errors when running this in cleanup.
      f477f555
    • R
      bhyve: do not cleanup unallocated networks on fail · 5c1f82ef
      Roman Bogorodskiy 提交于
      virBhyveProcessStart() calls bhyveNetCleanup() if it fails. However,
      it might fail earlier than networks are allocated, so modify
      bhyveNetCleanup() to check if net->ifname is not NULL before
      going further with the cleanup.
      5c1f82ef
  20. 13 6月, 2014 1 次提交
    • R
      bhyve: implement PCI address allocation · aad479dc
      Roman Bogorodskiy 提交于
      Automatically allocate PCI addresses for devices instead
      of hardcoding them in the driver code. The current
      allocation schema is to dedicate an entire slot for each devices.
      
      Also, allow having arbitrary number of devices.
      aad479dc
  21. 05 5月, 2014 1 次提交
    • R
      bhyve: report cpuTime in bhyveDomainGetInfo · 0541727c
      Roman Bogorodskiy 提交于
      Add a helper function virBhyveGetDomainTotalCpuStats() to
      obtain process CPU time using kvm (kernel memory interface)
      and use it to set cpuTime field of the virDomainInfo struct in
      bhyveDomainGetInfo().
      0541727c
  22. 04 5月, 2014 1 次提交
    • R
      bhyve: improve bhyve_command.c testability · 07e371fc
      Roman Bogorodskiy 提交于
      * bhyve_command.c (bhyveBuildNetArgStr, virBhyveProcessBuildBhyveCmd):
        add dryRun mode which doesn't create any devices when enabled
      * bhyve_command.c (virBhyveProcessBuildBhyveCmd,
        virBhyveProcessBuildDestroyCmd, virBhyveProcessBuildLoadCmd): accept
        virDomainDefPtr instead of virDomainObjPtr.
      07e371fc
  23. 31 3月, 2014 1 次提交
    • R
      bhyve: don't leak tap devices on failures · 1d8be343
      Roman Bogorodskiy 提交于
      On failures, virBhyveProcessStart() does not cleanup network
      interfaces that could be created by virBhyveProcessBuildBhyveCmd(),
      which results in a leaked tap device.
      
      To fix that, extract network cleanup code to bhyveNetCleanup()
      and use it in cleanup stage of virBhyveProcessStart().
      1d8be343
  24. 25 3月, 2014 1 次提交
  25. 23 3月, 2014 1 次提交
  26. 18 3月, 2014 1 次提交
  27. 04 3月, 2014 1 次提交
    • E
      util: make it easier to grab only regular command exit · b9dd878f
      Eric Blake 提交于
      Auditing all callers of virCommandRun and virCommandWait that
      passed a non-NULL pointer for exit status turned up some
      interesting observations.  Many callers were merely passing
      a pointer to avoid the overall command dying, but without
      caring what the exit status was - but these callers would
      be better off treating a child death by signal as an abnormal
      exit.  Other callers were actually acting on the status, but
      not all of them remembered to filter by WIFEXITED and convert
      with WEXITSTATUS; depending on the platform, this can result
      in a status being reported as 256 times too big.  And among
      those that correctly parse the output, it gets rather verbose.
      Finally, there were the callers that explicitly checked that
      the status was 0, and gave their own message, but with fewer
      details than what virCommand gives for free.
      
      So the best idea is to move the complexity out of callers and
      into virCommand - by default, we return the actual exit status
      already cleaned through WEXITSTATUS and treat signals as a
      failed command; but the few callers that care can ask for raw
      status and act on it themselves.
      
      * src/util/vircommand.h (virCommandRawStatus): New prototype.
      * src/libvirt_private.syms (util/command.h): Export it.
      * docs/internals/command.html.in: Document it.
      * src/util/vircommand.c (virCommandRawStatus): New function.
      (virCommandWait): Adjust semantics.
      * tests/commandtest.c (test1): Test it.
      * daemon/remote.c (remoteDispatchAuthPolkit): Adjust callers.
      * src/access/viraccessdriverpolkit.c (virAccessDriverPolkitCheck):
      Likewise.
      * src/fdstream.c (virFDStreamCloseInt): Likewise.
      * src/lxc/lxc_process.c (virLXCProcessStart): Likewise.
      * src/qemu/qemu_command.c (qemuCreateInBridgePortWithHelper):
      Likewise.
      * src/xen/xen_driver.c (xenUnifiedXendProbe): Simplify.
      * tests/reconnect.c (mymain): Likewise.
      * tests/statstest.c (mymain): Likewise.
      * src/bhyve/bhyve_process.c (virBhyveProcessStart)
      (virBhyveProcessStop): Don't overwrite virCommand error.
      * src/libvirt.c (virConnectAuthGainPolkit): Likewise.
      * src/openvz/openvz_driver.c (openvzDomainGetBarrierLimit)
      (openvzDomainSetBarrierLimit): Likewise.
      * src/util/virebtables.c (virEbTablesOnceInit): Likewise.
      * src/util/viriptables.c (virIpTablesOnceInit): Likewise.
      * src/util/virnetdevveth.c (virNetDevVethCreate): Fix debug
      message.
      * src/qemu/qemu_capabilities.c (virQEMUCapsInitQMP): Add comment.
      * src/storage/storage_backend_iscsi.c
      (virStorageBackendISCSINodeUpdate): Likewise.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      b9dd878f
  28. 19 2月, 2014 1 次提交
    • R
      bhyve: add a basic driver · 0eb4a5f4
      Roman Bogorodskiy 提交于
      At this point it has a limited functionality and is highly
      experimental. Supported domain operations are:
      
        * define
        * start
        * destroy
        * dumpxml
        * dominfo
      
      It's only possible to have only one disk device and only one
      network, which should be of type bridge.
      0eb4a5f4