1. 11 3月, 2019 1 次提交
  2. 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
  3. 07 3月, 2019 6 次提交
  4. 05 3月, 2019 3 次提交
  5. 04 3月, 2019 2 次提交
  6. 25 2月, 2019 1 次提交
  7. 22 2月, 2019 1 次提交
  8. 18 2月, 2019 3 次提交
  9. 07 2月, 2019 1 次提交
  10. 02 2月, 2019 2 次提交
  11. 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
  12. 31 1月, 2019 2 次提交
  13. 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
  14. 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
  15. 25 1月, 2019 3 次提交
  16. 19 12月, 2018 1 次提交
  17. 14 12月, 2018 1 次提交
  18. 03 12月, 2018 2 次提交
  19. 27 11月, 2018 1 次提交
  20. 16 11月, 2018 1 次提交
  21. 15 11月, 2018 2 次提交