1. 18 4月, 2016 1 次提交
  2. 17 4月, 2016 1 次提交
    • R
      ZFS: Support sparse volumes · c81bba4f
      Richard Laager 提交于
      By default, `zfs create -V ...` reserves space for the entire volsize,
      plus some extra (which attempts to account for overhead).
      
      If `zfs create -s -V ...` is used instead, zvols are (fully) sparse.
      
      A middle ground (partial allocation) can be achieved with
      `zfs create -s -o refreservation=... -V ...`.  Both libvirt and ZFS
      support this approach, so the ZFS storage backend should support it.
      Signed-off-by: NRichard Laager <rlaager@wiktel.com>
      c81bba4f
  3. 16 4月, 2016 6 次提交
    • J
      Resolve a couple of memory leaks · 727a3c58
      John Ferlan 提交于
      Commit id '4b75237f' seems to have triggered Coverity into finding
      at least one memory leak in xen_xl.c for error path for cleanup where
      the listenAddr would be leaked. Reviewing other callers, it seems that
      qemu_parse_command.c would have the same issue, so just it too.
      727a3c58
    • J
      tools: Fix memory leak · cb31d618
      John Ferlan 提交于
      Coverity found that commit id 'c661b675' needed to create a cleanup
      path to handle the closing of 'fp' if the virBitmapNewQuiet failed.
      cb31d618
    • J
      qemu: Fix qemuBuildCommandLine prototype · 6c09c17e
      John Ferlan 提交于
      Commit id '0da965c5' removed the 11th parameter, but neglected to
      remove the ATTRIBUTE_NONNULL for it and adjust the 17th and 18th.
      6c09c17e
    • J
      libxl: use LIBXL_API_VERSION 0x040200 · e7440656
      Jim Fehlig 提交于
      To ensure the libvirt libxl driver will build with future versions
      of Xen where the libxl API may change in incompatible ways,
      explicitly use LIBXL_API_VERSION 0x040200. The libxl driver
      does use new libxl APIs that have been added since Xen 4.2, but
      currently it does not make use of any changes made to existing
      APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity.
      The version can be bumped if/when the libxl driver consumes the
      changed APIs.
      
      Further details can be found in the following discussion thread
      
      https://www.redhat.com/archives/libvir-list/2016-April/msg00178.htmlSigned-off-by: NJim Fehlig <jfehlig@suse.com>
      e7440656
    • M
      qemu: Label master key file · 744d74fa
      Martin Kletzander 提交于
      When creating the master key, we used mode 0600 (which we should) but
      because we were creating it as root, the file is not readable by any
      qemu running as non-root.  Fortunately, it's just a matter of labelling
      the file.  We are generating the file path few times already, so let's
      label it in the same function that has access to the path already.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      744d74fa
    • J
      ploop: Fix build with gluster · 00307b5d
      Jiri Denemark 提交于
      Recent patches addiing support for ploop volumes did not properly update
      gluster backend.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      00307b5d
  4. 15 4月, 2016 32 次提交
    • R
      Add functions for handling exponential backoff loops. · beaa447a
      Richard W.M. Jones 提交于
      In a few places in libvirt we busy-wait for events, for example qemu
      creating a monitor socket.  This is problematic because:
      
       - We need to choose a sufficiently small polling period so that
         libvirt doesn't add unnecessary delays.
      
       - We need to choose a sufficiently large polling period so that
         the effect of busy-waiting doesn't affect the system.
      
      The solution to this conflict is to use an exponential backoff.
      
      This patch adds two functions to hide the details, and modifies a few
      places where we currently busy-wait.
      Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>
      beaa447a
    • O
      storage: dir: adapt .uploadVol .dowloadVol for ploop volume · 03e750f3
      Olga Krishtal 提交于
      In case of ploop volume, target path of the volume is the path to the
      directory that contains image file named root.hds and DiskDescriptor.xml.
      While using uploadVol and downloadVol callbacks we need to open root.hds
      itself.
      Upload or download operations with ploop volume are only allowed when
      images do not have snapshots. Otherwise operation fails.
      Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      03e750f3
    • O
      storage: dir: adapt .refreshVol and .refreshPool for ploop volumes · ea94be47
      Olga Krishtal 提交于
      Refreshes meta-information such as allocation, capacity, format, etc.
      Ploop volumes differ from other volume types. Path to volume is the path
      to directory with image file root.hds and DiskDescriptor.xml.
      https://openvz.org/Ploop/format
      Due to this fact, operations of opening the volume have to be done once
      again. get the information.
      
      To decide whether the given volume is ploops one, it is necessary to check
      the presence of root.hds and DiskDescriptor.xml files in volumes' directory.
      Only in this case the volume can be manipulated as the ploops one.
      Such strategy helps us to resolve problems that might occure, when we
      upload some other volume type from ploop source.
      Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      ea94be47
    • O
      storage: dir: .wipeVol is left unsupported for ploop volume · 0927fb3e
      Olga Krishtal 提交于
      Returns error in case of vol-wipe cmd for a ploop volume
      Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
      0927fb3e
    • O
      storage: dir: .resizeVol callback for ploop volume · d957ba8d
      Olga Krishtal 提交于
      Changes the size of given ploop volume via ploop resize tool.
      Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
      d957ba8d
    • O
      storage: dir: .deleteVol callback for ploop volume · 02d1e456
      Olga Krishtal 提交于
      Recursively deletes whole directory of a ploop volume.
      To delete ploop image it has to be unmounted.
      Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
      02d1e456
    • O
      storage: dir: .buildVol and .buildVolFrom callbacks for ploop · cff2138b
      Olga Krishtal 提交于
      These callbacks let us to create ploop volumes in dir, fs and etc. pools.
      If a ploop volume was created via buildVol callback, then this volume
      is an empty ploop device with DiskDescriptor.xml.
      If the volume was created via .buildFrom - then its content is similar to
      input volume content.
      Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      cff2138b
    • O
      storage: add ploop volume type · ee369755
      Olga Krishtal 提交于
      Ploop image consists of directory with two files: ploop image itself,
      called root.hds and DiskDescriptor.xml that contains information about
      ploop device: https://openvz.org/Ploop/format.
      Such volume are difficult to manipulate in terms of existing volume types
      because they are neither a single files nor a directory.
      This patch introduces new volume type - ploop. This volume type is used
      by ploop volume's exclusively.
      Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      ee369755
    • A
      cfg.mk: Get rid of quotation tricks · 294d22c8
      Andrea Bolognani 提交于
      To prevent the error messages in cfg.mk from triggering the very
      same rules they're supposed to explain, we split the message in
      the middle of a symbol name, ending up with stuff like
      
        'I am a me'ssage
      
      Instead of relying on these quotation tricks, simply exclude
      cfg.mk from the relevant checks.
      294d22c8
    • N
    • P
      qemu: hotplug: Properly recalculate/reload balloon size after hot(un)plug · 6306ee62
      Peter Krempa 提交于
      Rather than trying some magic calculations on our side query the monitor
      for the current size of the memory balloon both on hotplug and
      hotunplug.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1220702
      6306ee62
    • P
      qemu: process: Simplify condition in qemuProcessRefreshBalloonState · 1996da21
      Peter Krempa 提交于
      No need to store failure and re-check right away.
      1996da21
    • P
      c0e962b6
    • P
      d6cb0d25
    • P
      qemu: command: Refactor memballoon command line formatting · 33b9598c
      Peter Krempa 提交于
      Now that there is just one format of the memory balloon command line
      used the code can be merged into a single function.
      
      Additionally with some tweaks to the control flow the code is easier to
      read.
      33b9598c
    • P
      qemu: command: Drop obsolete comment · 388b356e
      Peter Krempa 提交于
      The change that made qemu not add the memballoon by default happened
      prior to 0.12.0. Additionaly the comment was misleading due to the code
      that was added below. Since we always need to add a balloon on the
      commandline drop the comment.
      388b356e
    • P
      qemu: caps: Deprecate QEMU_CAPS_BALLOON · 2242a008
      Peter Krempa 提交于
      The flag is now unused and all qemus supported by libvirt already
      support it.
      2242a008
    • P
    • C
      spec: Only pull in API docs with -devel package · feffcc03
      Cole Robinson 提交于
      Move some API specific documentation out of -docs package and into
      -devel, and some end user docs out of -devel and into -docs, then
      drop the -devel dep on -docs. This is more in line with the suggested
      Fedora guidelines.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1310155
      feffcc03
    • C
      qemu: migration: Drop dead VNC cookie handling · dae0e227
      Cole Robinson 提交于
      The only caller of this code is:
      
          for (i = 0; i < dom->def->ngraphics; i++) {
             if (dom->def->graphics[i]->type == VIR_DOMAIN_GRAPHICS_TYPE_SPICE) {
                 if (!(mig->graphics =
                       qemuMigrationCookieGraphicsAlloc(driver, dom->def->graphics[i])))
                     return -1;
                 mig->flags |= QEMU_MIGRATION_COOKIE_GRAPHICS;
                 break;
             }
          }
      
      So this is never triggered for VNC, and in fact VNC has no support for
      seamless migration anyways so that seems correct. Drop the dead VNC
      handling.
      dae0e227
    • E
      makefile: Move include/Makefile.am to include/libvirt/Makefile.am · ab517a5c
      Erik Skultety 提交于
      The reason for this is to fix the automatic rebuild of libvirt-common.h.in.
      All *.in files should be automatically rebuilt each time they're modified.
      It works well for makefiles and pkgconfig files, since they do have a valid
      dependency in the top-level Makefile. However, with libvirt-common.h.in
      there is no dependency in the top-level Makefile and there's no need for it
      either, so this rule
      
      include/libvirt/libvirt-common.h: $(top_builddir)/config.status \
              $(top_srcdir)/include/libvirt/libvirt-common.h.in
          cd $(top_builddir) && $(SHELL) ./config.status $@
      
      is never hit and should be moved to include/Makefile, but that's automake's
      job. According to GNU automake docs:
      
      "Files created by AC_CONFIG_FILES, be they
      Automake Makefiles or not, are all removed by ‘make distclean’. Their inputs
      are automatically distributed, unless they are the output of prior
      AC_CONFIG_FILES commands. Finally, rebuild rules are generated in the Automake
      Makefile existing in the subdirectory of the output file, if there is one, or
      in the top-level Makefile otherwise."
      
      Which means that if we want to have the rule for libvirt-common.h automatically
      generated by automake, the include/Makefile.am needs to be moved into libvirt/
      subdirectory and $SUBDIRS in the top-level Makefile need to be adjusted as
      well. This patch moves Makefile.am from include/ to include/libvirt, adjusting
      the prefixes accordingly as well as updates the top-level Makefile $SUBDIRS to
      properly hint automake to generate all rules at proper places.
      
      Best way to see the changes, use -M with 'git show'.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      ab517a5c
    • M
      vz: make it possible to use shared drivers API with vz driver connection · 9e783db2
      Maxim Nestratov 提交于
      Since vz driver is now lives as a part of daemon we can benefit from
      this fact and allow vz clients to use shared drivers API like storage,
      network, nwfilter etc.
      Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
      9e783db2
    • L
      qemu: support new pci controller model "pcie-expander-bus" · 8b62c65d
      Laine Stump 提交于
      This is backed by the qemu device pxb-pcie, which will be available in
      qemu 2.6.0.
      
      As with pci-expander-bus (which uses qemu's pxb device), the busNr
      attribute and <node> subelement of <target> are used to set the bus_nr
      and numa_node options.
      
      During post-parse we validate that the domain's machinetype is
      q35-based (since the device shows up for 440fx-based machinetypes, but
      is unusable), as well as checking that <node> specifies a node that is
      actually configured on the guest.
      8b62c65d
    • L
      conf: new pci controller model pcie-expander-bus · bc07251f
      Laine Stump 提交于
      This controller provides a single PCIe port on a new root. It is
      similar to pci-expander-bus, intended to provide a bus that can be
      associated with a guest-identifiable NUMA node, but is for
      machinetypes with PCIe rather than PCI (e.g. q35-based machinetypes).
      
      Aside from PCIe vs. PCI, the other main difference is that a
      pci-expander-bus has a companion pci-bridge that is automatically
      attached along with it, but pcie-expander-bus has only a single port,
      and that port will only connect to a pcie-root-port, or to a
      pcie-switch-upstream-port. In order for the bus to be of any use in
      the guest, it must have either a pcie-root-port or a
      pcie-switch-upstream-port attached (and one or more
      pcie-switch-downstream-ports attached to the
      pcie-switch-upstream-port).
      bc07251f
    • L
      qemu: add capabilities bit for device "pxb-pcie" · 0ec0bc85
      Laine Stump 提交于
          The pxb device is a PCIe expander bus that can be added to any
          Q35-based machinetype. A single PCIe port (*not* hotpluggable) is
          provided; if more than one device is desired, or if hotplug
          support is needed, either a pcie-root-port, or some combination of
          pcie-switch-upstream-port and pcie-swith-downstream-ports must be
          added to it. It can have a NUMA node number associated with it, as
          well as a bus number.
      0ec0bc85
    • L
      qemu: support new pci controller model "pci-expander-bus" · 400b2976
      Laine Stump 提交于
      This is backed by the qemu device "pxb".
      
      The pxb device always includes a pci-bridge that is at the bus number
      of the pxb + 1.
      
      busNr and <node> from the <target> subelement are used to set the
      bus_nr and numa_node options for pxb.
      
      During post-parse we validate that the domain's machinetype is
      440fx-based (since the pxb device only works on 440fx-based machines),
      and <node> also gets a sanity check to assure that the NUMA node
      specified for the pxb (if any - it's optional) actually exists on the
      guest.
      400b2976
    • L
      conf: new pci controller model pci-expander-bus · 52f3d0a4
      Laine Stump 提交于
      This is a standard PCI root bus (not a bridge) that can be added to a
      440fx-based domain. Although it uses a PCI slot, this is *not* how it
      is connected into the PCI bus hierarchy, but is only used for
      control. Each pci-expander-bus provides 32 slots (0-31) that can
      accept hotplug of standard PCI devices.
      
      The usefulness of pci-expander-bus relative to a pci-bridge is that
      the NUMA node of the bus can be specified with the <node> subelement
      of <target>. This gives guest-side visibility to the NUMA node of
      attached devices (presuming that management apps only assign a device
      to a bus that has a NUMA node number matching the node number of the
      device on the host).
      
      Each pci-expander-bus also has a "busNr" attribute. The expander-bus
      itself will take the busNr specified, and all buses that are connected
      to this bus (including the pci-bridge that is automatically added to
      any expander bus of model "pxb" (see the next commit)) will use
      busNr+1, busNr+2, etc, and the pci-root (or the expander-bus with next
      lower busNr) will use bus numbers lower than busNr.
      52f3d0a4
    • L
      qemu: add capabilities bit for device "pxb" · 5d4e2b17
      Laine Stump 提交于
      The pxb device is a PCI expander bus that can be added to any
      440fx-based machinetype. The PCI bus that is created has 32 standard
      PCI slots (hotpluggable). It can have a NUMA node number associated
      with it, as well as a bus number.
      5d4e2b17
    • L
      qemu: set PCI controller default modelName in a separate function · 1da28473
      Laine Stump 提交于
      Since every PCI controller model has to have a default model name set,
      put it in a separate function to clean up qemuDomainAssignPCIAddresses
      a bit.
      1da28473
    • L
      conf: utility function to convert PCI controller model into connect type · a0616ee8
      Laine Stump 提交于
      There are two places in qemu_domain_address.c where we have a switch
      statement to convert PCI controller models
      (VIR_DOMAIN_CONTROLLER_MODEL_PCI*) into the connection type flag that
      is matched when looking for an upstream connection for that model of
      controller (VIR_PCI_CONNECT_TYPE_*). This patch makes a utility
      function in conf/domain_addr.c to do that, so that when a new PCI
      controller is added, we only need to add the new model-->connect-type
      in a single place.
      a0616ee8
    • L
      conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work · d1cc4605
      Laine Stump 提交于
      The flags used to determine which devices could be plugged into which
      controllers were quite confusing, as they tried to create classes of
      connections, then put particular devices into possibly multiple
      classes, while sometimes setting multiple flags for the controllers
      themselves. The attempt to have a single flag indicate, e.g. that a
      root-port or a switch-downstream-port could connect was not only
      confusing, it was leading to a situation where it would be impossible
      to specify exactly the right combinations for a new controller.
      
      The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
      correspondence with each type of PCI controller, plus a flag for a PCI
      endpoint device and another for a PCIe endpoint device (the only
      exception to this is that pci-bridge and pcie-expander-bus controllers
      have their upstream connection classified as
      VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
      *exactly* the same ports as any endpoint device).  Each device then
      has a single flag for connect type (plus the HOTPLUG flag if that
      device can e hotplugged), and each controller sets the CONNECT bits
      for all controllers that can be plugged into it, as well as for either
      type of endpoint device that can be plugged in (and the HOTPLUG flag
      if it can accept hotplugged devices).
      
      With this change, it is *slightly* easier to understand the matching
      of connections (as long as you remember that the flag for a
      device/upstream-facing connection of a controller is the same as that
      device's type, while the flags for a controller's downstream
      connections is the OR of all device types that can be plugged into
      that controller). More importantly, it will be possible to correctly
      specify what can be plugged into a pcie-switch-expander-bus, when
      support for it is added.
      d1cc4605
    • L
      conf: allow use of slot 0 in a dmi-to-pci-bridge · 0d668434
      Laine Stump 提交于
      When support for dmi-to-pci-bridge was added, it was assumed that,
      just as with the pci-root bus, slot 0 was reserved. This is not the
      case - it can be used to connect a device just like any other slot, so
      remove the restriction and update the test cases that auto-assign an
      address on a dmi-to-pci-bridge.
      0d668434