1. 17 6月, 2015 2 次提交
  2. 03 6月, 2015 1 次提交
  3. 27 1月, 2015 2 次提交
    • D
      Removing probing of secondary drivers · 55ea7be7
      Daniel P. Berrange 提交于
      For stateless, client side drivers, it is never correct to
      probe for secondary drivers. It is only ever appropriate to
      use the secondary driver that is associated with the
      hypervisor in question. As a result the ESX & HyperV drivers
      have both been forced to do hacks where they register no-op
      drivers for the ones they don't implement.
      
      For stateful, server side drivers, we always just want to
      use the same built-in shared driver. The exception is
      virtualbox which is really a stateless driver and so wants
      to use its own server side secondary drivers. To deal with
      this virtualbox has to be built as 3 separate loadable
      modules to allow registration to work in the right order.
      
      This can all be simplified by introducing a new struct
      recording the precise set of secondary drivers each
      hypervisor driver wants
      
      struct _virConnectDriver {
          virHypervisorDriverPtr hypervisorDriver;
          virInterfaceDriverPtr interfaceDriver;
          virNetworkDriverPtr networkDriver;
          virNodeDeviceDriverPtr nodeDeviceDriver;
          virNWFilterDriverPtr nwfilterDriver;
          virSecretDriverPtr secretDriver;
          virStorageDriverPtr storageDriver;
      };
      
      Instead of registering the hypervisor driver, we now
      just register a virConnectDriver instead. This allows
      us to remove all probing of secondary drivers. Once we
      have chosen the primary driver, we immediately know the
      correct secondary drivers to use.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      55ea7be7
    • D
      don't disable state driver when libvirtd is not built · 220c01aa
      Daniel P. Berrange 提交于
      A bunch of code is wrapped in #if WITH_LIBVIRTD in order to
      enable the virStateDriver to be disabled when libvirtd is not
      built. Disabling this code doesn't have any real functional
      benefit beyond removing 1 pointer from the virConnectPtr struct,
      while having a cost of many more conditionals.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      220c01aa
  4. 02 12月, 2014 1 次提交
    • M
      libvirt.c: Move virDomainGetFSInfo to libvirt-domain.c · 2cc8c44e
      Michal Privoznik 提交于
      Since our big split of libvirt.c there are only a few functions
      living there. The majority was moved to corresponding subfile,
      e.g. domain functions were moved to libvirt-domain.c. However,
      the patches for virDomainGetFSInfo() and virDomainFSInfoFree()
      introduction were posted prior the big split and merged after.
      This resulted in two domain functions landing in wrong file.
      Move them to the correct one.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      2cc8c44e
  5. 24 11月, 2014 1 次提交
  6. 29 10月, 2014 1 次提交
    • E
      maint: avoid static zero init in core files · 39871fce
      Eric Blake 提交于
      C guarantees that static variables are zero-initialized.  Some older
      compilers (and also gcc -fno-zero-initialized-in-bss) create larger
      binaries if you explicitly zero-initialize a static variable.
      
      * src/libvirt.c: Fix initialization.
      * src/util/viralloc.c: Likewise.
      * src/util/virdbus.c: Likewise.
      * src/util/virevent.c: Likewise.
      * src/util/virfile.c (safezero): Likewise.
      * src/util/virlog.c: Likewise.
      * src/util/virnetlink.c: Likewise.
      * src/util/virthread.h (VIR_ONCE_GLOBAL_INIT): Likewise.
      * src/util/virprocess.c (virProcessGetStartTime): Likewise.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      39871fce
  7. 24 10月, 2014 11 次提交
  8. 23 10月, 2014 1 次提交
  9. 15 10月, 2014 1 次提交
  10. 01 10月, 2014 1 次提交
  11. 25 9月, 2014 2 次提交
    • M
      virNodeAllocPages: Disallow RO connection · 92b0577d
      Michal Privoznik 提交于
      Due to a missing check the API can be successfully called even if
      the connection is ReadOnly. Fortunately, the API hasn't been
      released yet, so there's no need for a CVE.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      92b0577d
    • M
      Introduce virNodeAllocPages · fa5c5580
      Michal Privoznik 提交于
      A long time ago in a galaxy far, far away it has been decided
      that libvirt will manage not only domains but host as well. And
      with my latest work on qemu driver supporting huge pages, we miss
      the cherry on top: an API to allocate huge pages on the run.
      Currently users are forced to log into the host and adjust the
      huge pages pool themselves.  However, with this API the problem
      is gone - they can both size up and size down the pool.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      fa5c5580
  12. 23 9月, 2014 1 次提交
  13. 18 9月, 2014 9 次提交
  14. 12 9月, 2014 1 次提交
    • E
      blockjob: allow finer bandwidth tuning for set speed · 0a6a6b1a
      Eric Blake 提交于
      We stupidly modeled block job bandwidth after migration
      bandwidth, which in turn was an 'unsigned long' and therefore
      subject to 32-bit vs. 64-bit interpretations.  To work around
      the fact that 10-gigabit interfaces are possible but don't fit
      within 32 bits, the original interface took the number scaled
      as MiB/sec.  But this scaling is rather coarse, and it might
      be nice to tune bandwidth finer than in megabyte chunks.
      
      Several of the block job calls that can set speed are fed
      through a common interface, so it was easier to adjust them all
      at once.  Note that there is intentionally no flag for the new
      virDomainBlockCopy; there, since the API already uses a 64-bit
      type always, instead of a possible 32-bit type, and is brand
      new, it was easier to just avoid scaling issues.  As with the
      previous patch that adjusted the query side (commit db33cc24),
      omitting the new flag preserves old behavior, and the
      documentation now mentions limits of what happens when a 32-bit
      machine is on either client or server side.
      
      * include/libvirt/libvirt.h.in (virDomainBlockJobSetSpeedFlags)
      (virDomainBlockPullFlags)
      (VIR_DOMAIN_BLOCK_REBASE_BANDWIDTH_BYTES)
      (VIR_DOMAIN_BLOCK_COMMIT_BANDWIDTH_BYTES): New enums.
      * src/libvirt.c (virDomainBlockJobSetSpeed, virDomainBlockPull)
      (virDomainBlockRebase, virDomainBlockCommit): Document them.
      * src/qemu/qemu_driver.c (qemuDomainBlockJobSetSpeed)
      (qemuDomainBlockPull, qemuDomainBlockRebase)
      (qemuDomainBlockCommit, qemuDomainBlockJobImpl): Support new flag.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      0a6a6b1a
  15. 10 9月, 2014 2 次提交
    • J
      qemu: Recompute downtime and total time when migration completes · eaee338a
      Jiri Denemark 提交于
      Total time of a migration and total downtime transfered from a source to
      a destination host do not count with the transfer time to the
      destination host and with the time elapsed before guest CPUs are
      resumed. Thus, source libvirtd remembers when migration started and when
      guest CPUs were paused. Both timestamps are transferred to destination
      libvirtd which uses them to compute total migration time and total
      downtime. Obviously, this requires the time to be synchronized between
      the two hosts. The reported times are useless otherwise but they would
      be equally useless if we didn't do this recomputation so don't lose
      anything by doing it.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      eaee338a
    • J
      Add support for fetching statistics of completed jobs · 3a868816
      Jiri Denemark 提交于
      virDomainGetJobStats gains new VIR_DOMAIN_JOB_STATS_COMPLETED flag that
      can be used to fetch statistics of a completed job rather than a
      currently running job.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      3a868816
  16. 06 9月, 2014 2 次提交
    • E
      blockcopy: allow block device destination · b7e73585
      Eric Blake 提交于
      To date, anyone performing a block copy and pivot ends up with
      the destination being treated as <disk type='file'>.  While this
      works for data access for a block device, it has at least one
      noticeable shortcoming: virDomainGetBlockInfo() reports allocation
      differently for block devices visited as files (the size of the
      device) than for block devices visited as <disk type='block'>
      (the maximum sector used, as reported by qemu); and this difference
      is significant when trying to manage qcow2 format on block devices
      that can be grown as needed.
      
      Of course, the more powerful virDomainBlockCopy() API can already
      express the ability to set the <disk> type.  But a new API can't
      be backported, while a new flag to an existing API can; and it is
      also rather inconvenient to have to resort to the full power of
      generating XML when just adding a flag to the older call will do
      the trick.  So this patch enhances blockcopy to let the user flag
      when the resulting XML after the copy must list the device as
      type='block'.
      
      * include/libvirt/libvirt.h.in (VIR_DOMAIN_BLOCK_REBASE_COPY_DEV):
      New flag.
      * src/libvirt.c (virDomainBlockRebase): Document it.
      * tools/virsh-domain.c (opts_block_copy, blockJobImpl): Add
      --blockdev option.
      * tools/virsh.pod (blockcopy): Document it.
      * src/qemu/qemu_driver.c (qemuDomainBlockRebase): Allow new flag.
      (qemuDomainBlockCopy): Remember the flag, and make sure it is only
      used on actual block devices.
      * tests/qemuxml2argvdata/qemuxml2argv-disk-mirror.xml: Test it.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      b7e73585
    • E
      blockjob: allow finer bandwidth tuning for query · db33cc24
      Eric Blake 提交于
      While reviewing the new virDomainBlockCopy API, Peter Krempa
      pointed out that our existing design of using MiB/s for block
      job bandwidth is rather coarse, especially since qemu tracks
      it in bytes/s; so virDomainBlockCopy only accepts bytes/s.
      But once the new API is implemented for qemu, we will be in
      the situation where it is possible to set a value that cannot
      be accurately reflected back to the user, because the existing
      virDomainGetBlockJobInfo defaults to the coarser units.
      
      Fortunately, we have an escape hatch; and one that has already
      served us well in the past: we can use the flags argument to
      specify which scale to use (see virDomainBlockResize for prior
      art).  This patch fixes the query side of the API; made easier
      by previous patches that split the query side out from the
      modification code.  Later patches will address the virsh
      interface, as well retrofitting all other blockjob APIs to
      also accept a flag for toggling bandwidth units.
      
      * include/libvirt/libvirt.h.in (_virDomainBlockJobInfo)
      (VIR_DOMAIN_BLOCK_COPY_BANDWIDTH): Document sizing issues.
      (virDomainBlockJobInfoFlags): New enum.
      * src/libvirt.c (virDomainGetBlockJobInfo): Document new flag.
      * src/qemu/qemu_monitor.h (qemuMonitorBlockJobInfo): Add parameter.
      * src/qemu/qemu_monitor.c (qemuMonitorBlockJobInfo): Likewise.
      * src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockJobInfo):
      Likewise.
      * src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockJobInfo)
      (qemuMonitorJSONGetBlockJobInfoOne): Likewise. Don't scale here.
      * src/qemu/qemu_migration.c (qemuMigrationDriveMirror): Update
      callers.
      * src/qemu/qemu_driver.c (qemuDomainBlockPivot)
      (qemuDomainBlockJobImpl): Likewise.
      (qemuDomainGetBlockJobInfo): Likewise, and support new flag.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      db33cc24
  17. 28 8月, 2014 1 次提交