1. 19 6月, 2015 1 次提交
  2. 18 6月, 2015 3 次提交
  3. 16 6月, 2015 1 次提交
  4. 12 6月, 2015 2 次提交
  5. 11 6月, 2015 1 次提交
  6. 04 6月, 2015 1 次提交
    • P
      conf: Add new helpers to resolve virDomainModificationImpact to domain defs · 3d021381
      Peter Krempa 提交于
      virDomainLiveConfigHelperMethod that is used for this job now does
      modify the flags but still requires the callers to extract the correct
      definition objects.
      
      In addition coverity and other static analyzers are usually unhappy as
      they don't grasp the fact that @flags are upadted according to the
      correct def to be present.
      
      To work this issue around and simplify the calling chain let's add a new
      helper that will work only on drivers that always copy the persistent
      def to a transient at start of a vm. This will allow to drop a few
      arguments. The new function syntax will also fill two definition
      pointers rather than modifying the @flags parameter.
      3d021381
  7. 03 6月, 2015 2 次提交
    • P
      util: bitmap: Add virBitmapToDataBuf that does not allocate the buffer · 02a6c73f
      Peter Krempa 提交于
      Since some functions can be optimized by reusing the buffers that they
      already have instead of allocating and copying new ones, lets split
      virBitmapToData to two functions where one only converts the data and
      the second one is a wrapper that allocates the buffer if necessary.
      02a6c73f
    • P
      conf: Refactor emulatorpin handling · ee3da892
      Peter Krempa 提交于
      Store the emulator pinning cpu mask as a pure virBitmap rather than the
      virDomainPinDef since it stores only the bitmap and refactor
      qemuDomainPinEmulator to do the same operations in a much saner way.
      
      As a side effect virDomainEmulatorPinAdd and virDomainEmulatorPinDel can
      be removed since they don't add any value.
      ee3da892
  8. 21 5月, 2015 1 次提交
    • J
      Add wrappers for virDomainDiskIndexBy* · 865109b3
      Jiri Denemark 提交于
      Sometimes the only thing we need is the pointer to virDomainDiskDef and
      having to call virDomainDiskIndexBy* APIs, storing the disk index, and
      looking it up in the disks array is ugly. After this patch, we can just
      call virDomainDiskBy* and get the pointer in one step.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      865109b3
  9. 18 5月, 2015 1 次提交
  10. 16 5月, 2015 1 次提交
  11. 15 5月, 2015 1 次提交
  12. 14 5月, 2015 1 次提交
  13. 11 5月, 2015 3 次提交
    • P
      conf: Add helper to convert list of virDomains to a list of virDomainObjs · 83726a14
      Peter Krempa 提交于
      Add virDomainObjListConvert that will take a list of virDomains, apply
      filters and return a list of virDomainObjs.
      83726a14
    • P
      conf: Refactor domain list collection critical section · cbe7bbf7
      Peter Krempa 提交于
      Until now the virDomainListAllDomains API would lock the domain list and
      then every single domain object to access and filter it. This would
      potentially allow a unresponsive VM to block the whole daemon if a
      *listAllDomains call would get stuck.
      
      To avoid this problem this patch collects a list of referenced domain
      objects first from the list and then unlocks it right away. The
      expensive operation requiring locking of the domain object is executed
      after the list lock is dropped. While a single blocked domain will still
      lock up a listAllDomains call, the domain list won't be held locked and
      thus other APIs won't be blocked.
      
      Additionally this patch also fixes the lookup code, where we'd ignore
      the vm->removing flag and thus potentially return domain objects that
      would be deleted very soon so calling any API wouldn't make sense.
      
      As other clients also could benefit from operating on a list of domain
      objects rather than the public domain descriptors a new intermediate
      API - virDomainObjListCollect - is introduced by this patch.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1181074
      cbe7bbf7
    • P
      util: Make the virDomainListFree helper more universal · a5e89ae1
      Peter Krempa 提交于
      Extend it to a universal helper used for clearing lists of any objects.
      Note that the argument type is specifically void * to allow implicit
      typecasting.
      
      Additionally add a helper that works on non-NULL terminated arrays once
      we know the length.
      a5e89ae1
  14. 28 4月, 2015 5 次提交
    • L
      network: move auto-assign of bridge name from XML parser to net driver · a28d3e48
      Laine Stump 提交于
      We already check that any auto-assigned bridge device name for a
      virtual network (e.g. "virbr1") doesn't conflict with the bridge name
      for any existing libvirt network (via virNetworkSetBridgeName() in
      conf/network_conf.c).
      
      We also want to check that the name doesn't conflict with any bridge
      device created on the host system outside the control of libvirt
      (history: possibly due to the ploriferation of references to libvirt's
      bridge devices in HOWTO documents all around the web, it is not
      uncommon for an admin to manually create a bridge in their host's
      system network config and name it "virbrX"). To add such a check to
      virNetworkBridgeInUse() (which is called by virNetworkSetBridgeName())
      we would have to call virNetDevExists() (from util/virnetdev.c); this
      function calls ioctl(SIOCGIFFLAGS), which everyone on the mailing list
      agreed should not be done from an XML parsing function in the conf
      directory.
      
      To remedy that problem, this patch removes virNetworkSetBridgeName()
      from conf/network_conf.c and puts an identically functioning
      networkBridgeNameValidate() in network/bridge_driver.c (because it's
      reasonable for the bridge driver to call virNetDevExists(), although
      we don't do that yet because I wanted this patch to have as close to 0
      effect on function as possible).
      
      There are a couple of inevitable changes though:
      
      1) We no longer check the bridge name during
         virNetworkLoadConfig(). Close examination of the code shows that
         this wasn't necessary anyway - the only *correct* way to get XML
         into the config files is via networkDefine(), and networkDefine()
         will always call networkValidate(), which previously called
         virNetworkSetBridgeName() (and now calls
         networkBridgeNameValidate()). This means that the only way the
         bridge name can be unset during virNetworkLoadConfig() is if
         someone edited the config file on disk by hand (which we explicitly
         prohibit).
      
      2) Just on the off chance that somebody *has* edited the file by hand,
         rather than crashing when they try to start their malformed
         network, a check for non-NULL bridge name has been added to
         networkStartNetworkVirtual().
      
         (For those wondering why I don't instead call
         networkValidateBridgeName() there to set a bridge name if one
         wasn't present - the problem is that during
         networkStartNetworkVirtual(), the lock for the network being
         started has already been acquired, but the lock for the network
         list itself *has not* (because we aren't adding/removing a
         network). But virNetworkBridgeInuse() iterates through *all*
         networks (including this one) and locks each network as it is
         checked for a duplicate entry; it is necessary to lock each network
         even before checking if it is the designated "skip" network because
         otherwise some other thread might acquire the list lock and delete
         the very entry we're examining. In the end, permitting a setting of
         the bridge name during network start would require that we lock the
         entire network list during any networkStartNetwork(), which
         eliminates a *lot* of parallelism that we've worked so hard to
         achieve (it can make a huge difference during libvirtd startup). So
         rather than try to adjust for someone playing against the rules, I
         choose to instead give them the error they deserve.)
      
      3) virNetworkAllocateBridge() (now removed) would leak any "template"
         string set as the bridge name. Its replacement
         networkFindUnusedBridgeName() doesn't leak the template string - it
         is properly freed.
      a28d3e48
    • J
      qemu: Add support to Add/Delete IOThreads · a27ed6e7
      John Ferlan 提交于
      Add qemuDomainAddIOThread and qemuDomainDelIOThread in order to add or
      remove an IOThread to/from the host either for live or config optoins
      
      The implementation for the 'live' option will use the iothreadpids list
      in order to make decision, while the 'config' option will use the
      iothreadids list.  Additionally, for deletion each may have to adjust
      the iothreadpin list.
      
      IOThreads are implemented by qmp objects, the code makes use of the existing
      qemuMonitorAddObject or qemuMonitorDelObject APIs.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      a27ed6e7
    • J
      domain: Introduce virDomainIOThreadSchedDelId · c6e2dc80
      John Ferlan 提交于
      We're about to allow IOThreads to be deleted, but an iothreadid may be
      included in some domain thread sched, so add a new API to allow removing
      an iothread from some entry.
      
      Then during the writing of the threadsched data and an additional check
      to determine whether the bitmap is all clear before writing it out.
      c6e2dc80
    • J
      conf: Move virDomainPinIsDuplicate and make static · b96254d4
      John Ferlan 提交于
      Since it's only ever referenced in domain_conf.c, make the function
      static, but also will need to move it to somewhere before it's referenced
      rather than forward referencing it.
      b96254d4
    • J
      conf: Add new domain XML element 'iothreadids' · 93383c1f
      John Ferlan 提交于
      Adding a new XML element 'iothreadids' in order to allow defining
      specific IOThread ID's rather than relying on the algorithm to assign
      IOThread ID's starting at 1 and incrementing to iothreads count.
      
      This will allow future patches to be able to add new IOThreads by
      a specific iothread_id and of course delete any exisiting IOThread.
      
      Each iothreadids element will have 'n' <iothread> children elements
      which will have attribute "id".  The "id" will allow for definition
      of any "valid" (eg > 0) iothread_id value.
      
      On input, if any <iothreadids> <iothread>'s are provided, they will
      be marked so that we only print out what we read in.
      
      On input, if no <iothreadids> are provided, the PostParse code will
      self generate a list of ID's starting at 1 and going to the number
      of iothreads defined for the domain (just like the current algorithm
      numbering scheme).  A future patch will rework the existing algorithm
      to make use of the iothreadids list.
      
      On output, only print out the <iothreadids> if they were read in.
      93383c1f
  15. 24 4月, 2015 1 次提交
  16. 22 4月, 2015 1 次提交
    • L
      util: set MAC address for VF via netlink message to PF+VF# when possible · cb3fe38c
      Laine Stump 提交于
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1113474
      
      When we set the MAC address of a network device as a part of setting
      up macvtap "passthrough" mode (where the domain has an emulated netdev
      connected to a host macvtap device that has exclusive use of the
      physical device, and sets the device MAC address to match its own,
      i.e. "<interface type='direct'> <source mode='passthrough' .../>"), we
      use ioctl(SIOCSIFHWADDR) giving it the name of that device. This is
      true even if it is an SRIOV Virtual Function (VF).
      
      But, when we are setting the MAC address / vlan ID of a VF in
      preparation for "hostdev network" passthrough (this is where we set
      the MAC address and vlan id of the VF after detaching the host net
      driver and before assigning the device to the domain with PCI
      passthrough, i.e. "<interface type='hostdev'>", we do the setting via
      a netlink RTM_SETLINK message for that VF's Physical Function (PF),
      telling it the VF# we want to change. This sets an "administratively
      changed MAC" flag for that VF in the PF's driver, and from that point
      on (until the PF driver is reloaded, *not* merely the VF driver) that
      VF's MAC address can't be changed using ioctl(SIOCSIFHWADDR) - the
      only way to change it is via the PF with RTM_SETLINK.
      
      This means that if a VF is used for hostdev passthrough, it will have
      the admin flag set, and future attempts to use that VF for macvtap
      passthrough will fail.
      
      The solution to this problem is to check if the device being used for
      macvtap passthrough is actually a VF; if so, we use the netlink
      RTM_SETLINK message to the PF to set the VF's mac address instead of
      ioctl(SIOCSIFHWADDR) directly to the VF; if not, behavior does not
      change from previously.
      
      There are three pieces to making this work:
      
      1) virNetDevMacVLan(Create|Delete)WithVPortProfile() now call
         virNetDev(Replace|Restore)NetConfig() rather than
         virNetDev(Replace|Restore)MacAddress() (simply passing -1 for VF#
         and vlanid).
      
      2) virNetDev(Replace|Restore)NetConfig() check to see if the device is
         a VF. If so, they find the PF's name and VF#, allowing them to call
         virNetDev(Replace|Restore)VfConfig().
      
      3) To prevent mixups when detaching a macvtap passthrough device that
         had been attached while running an older version of libvirt,
         virNetDevRestoreVfConfig() is potentially given the preserved name
         of the VF, and if the proper statefile for a VF can't be found in
         the stateDir (${stateDir}/${pfname}_vf${vfid}),
         virNetDevRestoreMacAddress() is called instead (which will look in
         the file named ${stateDir}/${vfname}).
      
      This problem has existed in every version of libvirt that has both
      macvtap passthrough and interface type='hostdev'. Fortunately people
      seem to use one or the other though, so it hasn't caused any real
      world problem reports.
      cb3fe38c
  17. 21 4月, 2015 3 次提交
    • C
      caps: Use DomainDataLookup to replace GuestDefault* · 747761a7
      Cole Robinson 提交于
      This revealed that GuestDefaultEmulator was a bit buggy, capable
      of returning an emulator that didn't match the passed domain type. Fix
      up the test suite input to continue to pass.
      747761a7
    • C
      caps: Add virCapabilitiesDomainDataLookup · a6936523
      Cole Robinson 提交于
      This is a helper function to look up all capabilities data for all
      the OS bits that are relevant to <domain>. This is
      
      - os type
      - arch
      - domain type
      - emulator
      - machine type
      
      This will be used to replace several functions in later commits.
      a6936523
    • C
      caps: Use an enum internally for ostype value · 4231485c
      Cole Robinson 提交于
      But the internal API stays the same, and we just convert the value as
      needed. Not useful yet, but this is the beginning step of using an enum
      for ostype throughout the code.
      4231485c
  18. 17 4月, 2015 1 次提交
    • M
      Introduce virNetDevBandwidthUpdateFilter · 176a95fd
      Michal Privoznik 提交于
      This is a simple wrapper around virNetDevBandwidthManipulateFilter() that
      will update the desired filter on an interface (usually a network bridge)
      with a new MAC address. Although, the MAC address in question usually
      refers to some other interface - the one that the filter is constructed
      for. Yeah, hard to parse. Thing is, our NATed network has a bridge where
      some part of QoS takes place. And vNICs from guests are plugged into
      the bridge. However, if a guest decides to change the MAC of its vNIC,
      the corresponding qemu process emits an event which we can use to
      update the QoS configuration based on the new MAC address.. However,
      our QoS hierarchy is currently not notified, therefore it falls apart.
      This function (when called in response to the aforementioned event)
      will update our QoS hierarchy and duct tape it together again.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      176a95fd
  19. 16 4月, 2015 1 次提交
  20. 15 4月, 2015 3 次提交
  21. 14 4月, 2015 1 次提交
  22. 10 4月, 2015 3 次提交
  23. 08 4月, 2015 1 次提交
  24. 07 4月, 2015 1 次提交