1. 11 5月, 2016 12 次提交
    • J
      storage: Need to clear pool prior to calling the refreshPool · 5e54361c
      John Ferlan 提交于
      Prior to calling the 'refreshPool' during CreatePool or UploadPool
      operations, we need to clear the pool; otherwise, the pool will
      have duplicated entries.
      5e54361c
    • J
      storage: Fix regression cloning volume into a logical pool · 2c52ec43
      John Ferlan 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1318993
      
      Commit id 'dd519a29' caused a regression cloning a volume into a
      logical pool by removing just the 'allocation' adjustment during
      storageVolCreateXMLFrom. Combined with the change to not require the
      new volume input XML to have a capacity listed (commit id 'e3f1d2a8')
      left the possibility that a zero allocation value (e.g., not provided)
      would create a thin/sparse logical volume. When a thin lv becomes fully
      populated, then LVM sets the partition 'inactive' and the subsequent
      fdatasync() fails.
      
      Add a new 'has_allocation' flag to be set at XML parse time to indicate
      that allocation was provided. This is done so that if it's not provided
      the create-from code uses the capacity value since we document that if
      omitted, the volume will be fully allocated at time of creation.
      
      For a logical backend, that creation time is 'createVol', while for a
      file backend, creation doesn't set the size, but the 'createRaw' called
      during buildVolFrom will decide whether the file is sparse or not based
      on the provided capacity and allocation value.
      
      For volume clones that provide different allocation and capacity values
      to allow for sparse files, there is no change.
      2c52ec43
    • E
      headers: Remove unnecessary keyword extern from function declaration · 898c0bbe
      Erik Skultety 提交于
      Usage of this keyword in front of function declaration that is exported via a
      header file is unnecessary, since internally, this has been the default for most
      compilers for quite some time.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      898c0bbe
    • L
      conf: log error when incorrect PCI root controller is added to domain · e5aecc2f
      Laine Stump 提交于
      libvirt may automatically add a pci-root or pcie-root controller to a
      domain, depending on the arch/machinetype, and it hopefully always
      makes the right decision about which to add (since in all cases these
      controllers are an implicit part of the virtual machine).
      
      But it's always possible that someone will create a config that
      explicitly supplies the wrong type of PCI controller for the selected
      machinetype. In the past that would lead to an error later when
      libvirt was trying to assign addresses to other devices, for example:
      
        XML error: PCI bus is not compatible with the device at
        0000:00:02.0. Device requires a PCI Express slot, which is not
        provided by bus 0000:00
      
      (that's the error message that appears if you replace the pcie-root
      controller in a Q35 domain with a pci-root controller).
      
      This patch adds a check at the same place that the implicit
      controllers are added (to ensure that the same logic is used to check
      which type of pci root is correct). If a pci controller with index='0'
      is already present, we verify that it is of the model that we would
      have otherwise added automatically; if not, an error is logged:
      
        The PCI controller with index='0' must be " model='pcie-root' for
        this machine type, " but model='pci-root' was found instead.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1004602
      e5aecc2f
    • L
      conf: make virDomainDefAddController() public · b3f2c7ca
      Laine Stump 提交于
      This will be needed by the qemu driver in an upcoming patch.
      b3f2c7ca
    • J
      libxl: support migration stream V2 in migration · f9edcfa4
      Jim Fehlig 提交于
      Similar to "support Xen migration stream V2 in save/restore",
      add support for indicating the migration stream version in
      the migration code. To accomplish this, add a minimal migration
      cookie in the libxl driver that is passed between source and
      destination hosts. Initially, the cookie is only used in
      the Begin and Prepare phases of migration to communicate the
      version of the migration stream produced by the source.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      f9edcfa4
    • J
      libxl: support Xen migration stream V2 in save/restore · 5325123d
      Jim Fehlig 提交于
      Xen 4.6 introduced a new migration stream commonly referred to as
      "migration V2". Xen 4.6 and newer always produce this new stream,
      whereas Xen 4.5 and older always produce the legacy stream.
      Support for migration stream V2 can be detected at build time with
      LIBXL_HAVE_SRM_V2 from libxl.h. The legacy and V2 streams are not
      compatible, but a V2 host can accept and convert a legacy stream.
      
      Commit e7440656 changed the libxl driver to use the lowest libxl
      API version possible (version 0x040200) to ensure the driver
      builds against older Xen releases. The old 4.2 restore API does
      not support specifying a stream version and assumes a legacy
      stream, even if the incoming stream is migration V2. Thinking it
      has been given a legacy stream, libxl will fail to convert an
      incoming stream that is already V2, which causes the entire
      restore operation to fail. Xen's libvirt-related OSSTest has been
      failing since commit e7440656 landed in libvirt.git master. One
      of the more recent failures can be seen here
      
      http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00071.html
      
      This patch changes the call to libxl_domain_create_restore() to
      include the stream version if LIBXL_HAVE_SRM_V2 is defined. The
      version field of the libxlSavefileHeader struct is also updated
      to '2' when LIBXL_HAVE_SRM_V2 is defined, ensuring the stream
      version in the header matches the actual stream version produced
      by Xen. Along with bumping the libxl API requirement to 0x040400,
      this patch fixes save/restore on a migration V2 Xen host.
      
      Oddly, migration has never used the libxlSavefileHeader. It
      handles passing configuration in the Begin and Prepare phases,
      and then calls libxl directly to transfer domain state/memory
      in the Perform phase. A subsequent patch will add stream
      version handling in the Begin and Prepare phase handshaking,
      which will fix the migration related OSSTest failures.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      5325123d
    • J
      libxl: switch to using libxl_domain_create_restore from v4.4 API · fccf2725
      Jim Fehlig 提交于
      In LIBXL_API_VERSION 0x040400, the libxl_domain_create_restore API
      gained a parameter for specifying restore parameters. Switch to
      using version 0x040400, which will be useful in a subsequent commit
      to specify the Xen migration stream version when restoring.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      fccf2725
    • J
      docs: Fix disk "volume" description · 70ac2461
      John Ferlan 提交于
      Missing a close single quote and a 'be' before used.
      70ac2461
    • J
      qemu: Add extra checks for secret destroy API's · fc5c1e7f
      John Ferlan 提交于
      Remove the possibility that a NULL hostdev->privateData or a
      disk->privateData could crash libvirtd by checking for NULL
      before dereferencing for the secinfo structure in the
      qemuDomainSecret{Disk|Hostdev}Destroy functions. The hostdevPriv
      could be NULL if qemuProcessNetworkPrepareDevices adds a new
      hostdev during virDomainNetGetActualHostdev that then gets
      inserted via virDomainHostdevInsert. The hostdevPriv was added
      by commit id '27726d8c' and is currently only used by scsi hostdev.
      fc5c1e7f
    • L
      docs: fix version number in vlan tagging documentation · f21017ab
      Laine Stump 提交于
      My brain suffered a time warp and I got the version number wrong.
      f21017ab
    • L
      util: set vlan tag for macvtap passthrough mode on SRIOV VFs · 75db9997
      Laine Stump 提交于
      SRIOV VFs used in macvtap passthrough mode can take advantage of the
      SRIOV card's transparent vlan tagging. All the code was there to set
      the vlan tag, and it has been used for SRIOV VFs used for hostdev
      interfaces for several years, but for some reason, the vlan tag for
      macvtap passthrough devices was stubbed out with a -1.
      
      This patch moves a bit of common validation down to a lower level
      (virNetDevReplaceNetConfig()) so it is shared by hostdev and macvtap
      modes, and updates the macvtap caller to actually send the vlan config
      instead of -1.
      75db9997
  2. 10 5月, 2016 18 次提交
  3. 09 5月, 2016 10 次提交