1. 22 3月, 2019 3 次提交
    • E
      snapshot: Add accessors for updating snapshot list relations · 02c4e24d
      Eric Blake 提交于
      Rather than allowing a leaky abstraction where multiple drivers have
      to open-code operations that update the relations in a
      virDomainSnapshotObjList, it is better to add accessor functions so
      that updates to relations are maintained closer to the internals.
      This patch finishes the job started in the previous patch, by getting
      rid of all direct access to nchildren, first_child, or sibling outside
      of the lowest level functions, making it easier to refactor later on.
      
      The lone new caller to virDomainSnapshotObjListSize() checks for a
      return != 0, because it wants to handles errors (-1, only possible if
      the hash table wasn't allocated) and existing snapshots (> 0) in the
      same manner; we can drop the check for a current snapshot on the
      grounds that there shouldn't be one if there are no snapshots.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      02c4e24d
    • E
      snapshot: Add accessor for reparenting snapshot children · ced0898f
      Eric Blake 提交于
      Rather than allowing a leaky abstraction where multiple drivers have
      to open-code operations that update the relations in a
      virDomainSnapshotObjList, it is better to add accessor functions so
      that updates to relations are maintained closer to the internals.
      This patch starts the task with a single new function:
      virDomainSnapshotMoveChildren(). The logic might not be immediately
      obvious [okay, that's an understatement - the existing code uses black
      magic ;-)], so here's an overview: The old code has an implicit for
      loop around each call to qemuDomainSnapshotReparentChildren() by using
      virDomainSnapshotForEachChild() (you'll need a wider context than
      git's default of 3 lines to see that); the new code has a more visible
      for loop. Then it helps if you realize that the code is making two
      separate changes to each child object: STRDUP of the new parent name
      prior to writing XML files (unchanged), and touching up the pointer to
      the parent object (refactored); the end result is the same whether a
      single pass made both changes (both in driver code), or whether it is
      split into two passes making one change each (one in driver code, the
      other in the new accessor).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      ced0898f
    • E
      snapshot: Track current snapshot in virDomainSnapshotObjList · 4819f54b
      Eric Blake 提交于
      It is easier to track the current snapshot as part of the list of
      snapshots. In particular, doing so lets us guarantee that the current
      snapshot is cleared if that snapshot is removed from the list (rather
      than depending on the caller to do so, and risking a use-after-free
      problem, such as the one recently patched in 1db9d0ef).  This
      requires the addition of several new accessor functions, as well as a
      useful return type for virDomainSnapshotObjListRemove().  A few error
      handling sites that were previously setting vm->current_snapshot =
      NULL can now be dropped, because the previous function call has now
      done it already.  Also, qemuDomainRevertToSnapshot() was setting the
      current vm twice, so keep only the one used on the success path.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      4819f54b
  2. 20 3月, 2019 1 次提交
    • M
      virnwfilterbindingobj: Introduce and use virNWFilterBindingObjStealDef · 8c08a997
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1686927
      
      When trying to create a nwfilter binding via
      nwfilterBindingCreateXML() we may encounter a crash. The sequence
      of functions called is as follows:
      
      1) nwfilterBindingCreateXML() parses the XML and calls
      virNWFilterBindingObjListAdd() which calls
      virNWFilterBindingObjListAddLocked()
      
      2) Here, @binding is not found because binding->remove is set.
      
      3) Therefore, controls continue with creating new @binding,
      setting its def to the one from 1) and adding it to the hash
      table.
      
      4) This fails, because the binding is still in the hash table
      (duplicate key is detected).
      
      5) The control jumps to 'error' label where
      virNWFilterBindingObjEndAPI() is called which frees the binding
      definition passed.
      
      6) Error is propagated to the caller, which calls
      virNWFilterBindingDefFree() over the definition again.
      
      The solution is to unset binding->def in case of failure so it's
      not freed in step 5).
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      8c08a997
  3. 19 3月, 2019 1 次提交
    • J
      storage: optional 'refresh' elemement on pool · 669018bc
      Jason Dillaman 提交于
      The new 'refresh' element can override the default refresh operations
      for a storage pool. The only currently supported override is to set
      the volume allocation size to the volume capacity. This can be specified
      by adding the following snippet:
      
      <pool>
      ...
        <refresh>
          <volume allocation='capacity'/>
        </refresh>
      ...
      </pool>
      
      This is useful for certain backends where computing the actual allocation
      of a volume might be an expensive operation.
      Signed-off-by: NJason Dillaman <dillaman@redhat.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      669018bc
  4. 16 3月, 2019 2 次提交
  5. 15 3月, 2019 1 次提交
  6. 14 3月, 2019 1 次提交
  7. 13 3月, 2019 1 次提交
  8. 12 3月, 2019 1 次提交
    • M
      conf: Introduce firmware attribute to <os/> · d947fa8a
      Michal Privoznik 提交于
      The idea is that using this attribute users enable libvirt to
      automagically select firmware image for their domain. For
      instance:
      
        <os firmware='efi'>
          <type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
          <loader secure='no'/>
        </os>
      
        <os firmware='bios'>
          <type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
        </os>
      
      (The automagic of selecting firmware image will be described in
      later commits.)
      
      Accepted values are 'bios' and 'efi' to let libvirt select
      corresponding type of firmware.
      
      I know it is a good sign to introduce xml2xml test case when
      changing XML config parser but that will have to come later.
      Firmware auto selection is not enabled for any driver just yet so
      any xml2xml test would fail right away.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      d947fa8a
  9. 11 3月, 2019 1 次提交
  10. 08 3月, 2019 3 次提交
    • E
      snapshot: Add virDomainSnapshotObjListParse · 1b57269c
      Eric Blake 提交于
      Add a new function to make it possible to parse a list of snapshots
      at once.  This is a counterpart to an earlier patch making it
      possible to produce all snapshots in a single XML string, and
      intentionally parses the same top-level element <snapshots> with
      an optional attribute current='name'.
      
      Note that since we know we started with no relations at all, and
      since checking parent relationships per-snapshot is not viable as
      we don't control which order the snapshots appear in, that we are
      fine with doing a final pass to update all parent/child
      relationships among the definitions.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      1b57269c
    • E
      snapshot: Add virDomainSnapshotObjListFormat · 86c0ed6f
      Eric Blake 提交于
      Add a new function to output all of the domain's snapshots in one
      buffer.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      86c0ed6f
    • E
      snapshot: Give virDomainSnapshotDefFormat its own flags · c5029559
      Eric Blake 提交于
      virDomainSnapshotDefFormat currently takes two sets of knobs:
      an 'unsigned int flags' argument that can currently just be
      VIR_DOMAIN_DEF_FORMAT_SECURE, and an 'int internal' argument used as
      a bool to determine whether to output an additional element.  It
      then reuses the 'flags' knob to call into virDomainDefFormatInternal(),
      which takes a different set of flags. In fact, prior to commit 0ecd6851
      (1.2.12), the 'flags' argument actually took the public
      VIR_DOMAIN_XML_SECURE, which was even more confusing.  Let's borrow
      from the style of that earlier commit, by introducing a function
      for translating from the public flags (VIR_DOMAIN_SNAPSHOT_XML_SECURE
      was just recently introduced) into a new enum specific to snapshot
      formatting, and adjust all callers to use snapshot-specific enum
      values when formatting, and where the formatter now uses a new
      variable 'domainflags' to make it obvious when we are translating
      from snapshot flags back to domain flags.  We don't even have to
      use the conversion function for drivers that don't accept the
      public VIR_DOMAIN_SNAPSHOT_XML_SECURE flag.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      c5029559
  11. 07 3月, 2019 6 次提交
  12. 05 3月, 2019 3 次提交
  13. 04 3月, 2019 2 次提交
  14. 25 2月, 2019 1 次提交
  15. 22 2月, 2019 1 次提交
  16. 18 2月, 2019 3 次提交
  17. 07 2月, 2019 1 次提交
  18. 02 2月, 2019 2 次提交
  19. 01 2月, 2019 1 次提交
    • J
      util: Introduce virStorageFileGetNPIVKey · 5f9e211c
      John Ferlan 提交于
      The vHBA/NPIV LUNs created via the udev processing of the
      VPORT_CREATE command end up using the same serial value
      as seen/generated by the /lib/udev/scsi_id as returned
      during virStorageFileGetSCSIKey. Therefore, in order to
      generate a unique enough key to be used when adding the
      LUN as a volume during virStoragePoolObjAddVol a more
      unique key needs to be generated for an NPIV volume.
      
      The problem is illustrated by the following example, where
      scsi_host5 is a vHBA used with the following LUNs:
      
      $ lsscsi -tg
      ...
      [5:0:4:0]    disk    fc:0x5006016844602198,0x101f00  /dev/sdh   /dev/sg23
      [5:0:5:0]    disk    fc:0x5006016044602198,0x102000  /dev/sdi   /dev/sg24
      ...
      
      Calling virStorageFileGetSCSIKey would return:
      
      /lib/udev/scsi_id --device /dev/sdh --whitelisted --replace-whitespace /dev/sdh
      350060160c460219850060160c4602198
      /lib/udev/scsi_id --device /dev/sdh --whitelisted --replace-whitespace /dev/sdi
      350060160c460219850060160c4602198
      
      Note that althrough /dev/sdh and /dev/sdi are separate LUNs, they
      end up with the same serial number used for the vol->key value.
      When virStoragePoolFCRefreshThread calls virStoragePoolObjAddVol
      the second LUN fails to be added with the following message
      getting logged:
      
          virHashAddOrUpdateEntry:341 : internal error: Duplicate key
      
      To resolve this, virStorageFileGetNPIVKey will use a similar call
      sequence as virStorageFileGetSCSIKey, except that it will add the
      "--export" option to the call. This results in more detailed output
      which needs to be parsed in order to formulate a unique enough key
      to be used. In order to be unique enough, the returned value will
      concatenate the target port as returned in the "ID_TARGET_PORT"
      field from the command to the "ID_SERIAL" value.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      5f9e211c
  20. 31 1月, 2019 2 次提交
  21. 30 1月, 2019 1 次提交
    • J
      conf: Introduce virStoragePoolXMLNamespace · fa7a66d0
      John Ferlan 提交于
      Introduce the infrastructure necessary to manage a Storage Pool XML
      Namespace. The general concept is similar to virDomainXMLNamespace,
      except that for Storage Pools the storage backend specific details
      can be stored within the _virStoragePoolOptions unlike the domain
      processing code which manages its xmlopt's via the virDomainXMLOption
      which is allocated/passed around for each domain.
      
      This patch defines the add the parse, format, free, and href methods
      required to process the XML and callout from the Storage Pool Def
      parse, format, and free API's to perform the action on the XML data
      for/from the backend.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      fa7a66d0
  22. 29 1月, 2019 2 次提交
    • D
      util: move virtual network firwall rules into private chains · 7431b3eb
      Daniel P. Berrangé 提交于
      The previous commit created new chains to hold the firewall rules. This
      commit changes the code that creates rules to place them in the new
      private chains instead of the builtin top level chains.
      
      With two networks running, the rules in the filter table now look like
      
        -N LIBVIRT_FWI
        -N LIBVIRT_FWO
        -N LIBVIRT_FWX
        -N LIBVIRT_INP
        -N LIBVIRT_OUT
        -A INPUT -j LIBVIRT_INP
        -A FORWARD -j LIBVIRT_FWX
        -A FORWARD -j LIBVIRT_FWI
        -A FORWARD -j LIBVIRT_FWO
        -A OUTPUT -j LIBVIRT_OUT
        -A LIBVIRT_FWI -d 192.168.0.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
        -A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
        -A LIBVIRT_FWI -d 192.168.1.0/24 -o virbr1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
        -A LIBVIRT_FWI -o virbr1 -j REJECT --reject-with icmp-port-unreachable
        -A LIBVIRT_FWO -s 192.168.0.0/24 -i virbr0 -j ACCEPT
        -A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable
        -A LIBVIRT_FWO -s 192.168.1.0/24 -i virbr1 -j ACCEPT
        -A LIBVIRT_FWO -i virbr1 -j REJECT --reject-with icmp-port-unreachable
        -A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT
        -A LIBVIRT_FWX -i virbr1 -o virbr1 -j ACCEPT
        -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
        -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
        -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
        -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
        -A LIBVIRT_INP -i virbr1 -p udp -m udp --dport 53 -j ACCEPT
        -A LIBVIRT_INP -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT
        -A LIBVIRT_INP -i virbr1 -p udp -m udp --dport 67 -j ACCEPT
        -A LIBVIRT_INP -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT
        -A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
        -A LIBVIRT_OUT -o virbr1 -p udp -m udp --dport 68 -j ACCEPT
      
      While in the nat table:
      
        -N LIBVIRT_PRT
        -A POSTROUTING -j LIBVIRT_PRT
        -A LIBVIRT_PRT -s 192.168.0.0/24 -d 224.0.0.0/24 -j RETURN
        -A LIBVIRT_PRT -s 192.168.0.0/24 -d 255.255.255.255/32 -j RETURN
        -A LIBVIRT_PRT -s 192.168.0.0/24 ! -d 192.168.0.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
        -A LIBVIRT_PRT -s 192.168.0.0/24 ! -d 192.168.0.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
        -A LIBVIRT_PRT -s 192.168.0.0/24 ! -d 192.168.0.0/24 -j MASQUERADE
        -A LIBVIRT_PRT -s 192.168.1.0/24 -d 224.0.0.0/24 -j RETURN
        -A LIBVIRT_PRT -s 192.168.1.0/24 -d 255.255.255.255/32 -j RETURN
        -A LIBVIRT_PRT -s 192.168.1.0/24 ! -d 192.168.1.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
        -A LIBVIRT_PRT -s 192.168.1.0/24 ! -d 192.168.1.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
        -A LIBVIRT_PRT -s 192.168.1.0/24 ! -d 192.168.1.0/24 -j MASQUERADE
      
      And finally the mangle table:
      
        -N LIBVIRT_PRT
        -A POSTROUTING -j LIBVIRT_PRT
        -A LIBVIRT_PRT -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
        -A LIBVIRT_PRT -o virbr1 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      7431b3eb
    • D
      util: create private chains for virtual network firewall rules · 5f1e6a7d
      Daniel P. Berrangé 提交于
      Historically firewall rules for virtual networks were added straight
      into the base chains. This works but has a number of bugs and design
      limitations:
      
        - It is inflexible for admins wanting to add extra rules ahead
          of libvirt's rules, via hook scripts.
      
        - It is not clear to the admin that the rules were created by
          libvirt
      
        - Each rule must be deleted by libvirt individually since they
          are all directly in the builtin chains
      
        - The ordering of rules in the forward chain is incorrect
          when multiple networks are created, allowing traffic to
          mistakenly flow between networks in one direction.
      
      To address all of these problems, libvirt needs to move to creating
      rules in its own private chains. In the top level builtin chains,
      libvirt will add links to its own private top level chains.
      
      Addressing the traffic ordering bug requires some extra steps. With
      everything going into the FORWARD chain there was interleaving of rules
      for outbound traffic and inbound traffic for each network:
      
        -A FORWARD -d 192.168.3.0/24 -o virbr1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
        -A FORWARD -s 192.168.3.0/24 -i virbr1 -j ACCEPT
        -A FORWARD -i virbr1 -o virbr1 -j ACCEPT
        -A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
        -A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
        -A FORWARD -d 192.168.2.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
        -A FORWARD -s 192.168.2.0/24 -i virbr0 -j ACCEPT
        -A FORWARD -i virbr0 -o virbr0 -j ACCEPT
        -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
        -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
      
      The rule allowing outbound traffic from virbr1 would mistakenly
      allow packets from virbr1 to virbr0, before the rule denying input
      to virbr0 gets a chance to run.
      
      What we really need todo is group the forwarding rules into three
      distinct sets:
      
       * Cross rules - LIBVIRT_FWX
      
        -A FORWARD -i virbr1 -o virbr1 -j ACCEPT
        -A FORWARD -i virbr0 -o virbr0 -j ACCEPT
      
       * Incoming rules - LIBVIRT_FWI
      
        -A FORWARD -d 192.168.3.0/24 -o virbr1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
        -A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
        -A FORWARD -d 192.168.2.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
        -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
      
       * Outgoing rules - LIBVIRT_FWO
      
        -A FORWARD -s 192.168.3.0/24 -i virbr1 -j ACCEPT
        -A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
        -A FORWARD -s 192.168.2.0/24 -i virbr0 -j ACCEPT
        -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
      
      There is thus no risk of outgoing rules for one network mistakenly
      allowing incoming traffic for another network, as all incoming rules
      are evalated first.
      
      With this in mind, we'll thus need three distinct chains linked from
      the FORWARD chain, so we end up with:
      
              INPUT --> LIBVIRT_INP   (filter)
      
             OUTPUT --> LIBVIRT_OUT   (filter)
      
            FORWARD +-> LIBVIRT_FWX   (filter)
                    +-> LIBVIRT_FWO
                    \-> LIBVIRT_FWI
      
        POSTROUTING --> LIBVIRT_PRT   (nat & mangle)
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      5f1e6a7d