1. 07 3月, 2019 1 次提交
  2. 05 3月, 2019 3 次提交
  3. 04 3月, 2019 2 次提交
  4. 25 2月, 2019 1 次提交
  5. 22 2月, 2019 1 次提交
  6. 18 2月, 2019 3 次提交
  7. 07 2月, 2019 1 次提交
  8. 02 2月, 2019 2 次提交
  9. 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
  10. 31 1月, 2019 2 次提交
  11. 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
  12. 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
  13. 25 1月, 2019 3 次提交
  14. 19 12月, 2018 1 次提交
  15. 14 12月, 2018 1 次提交
  16. 03 12月, 2018 2 次提交
  17. 27 11月, 2018 1 次提交
  18. 16 11月, 2018 1 次提交
  19. 15 11月, 2018 7 次提交
  20. 12 11月, 2018 1 次提交
    • E
      conf: Add new module node_device_util · f1e8d2f0
      Erik Skultety 提交于
      There's a lot of stuff going on in src/conf/nodedev_conf which is
      sometimes not directly related to config and we're not really consistent
      with putting only parser/formatter related stuff here, e.g. like we do
      for domains. So, let's start simply by adding a new module
      node_device_util containing some of the helpers. Unfortunately, even
      though these helpers tend to open a secondary driver connection and would
      be much therefore better suited as a nodedev driver module, we can't do
      that without pulling headers from the driver into conf/ and that's wrong
      because we want conf/ to stay driver-agnostic.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      Acked-by: NMichal Privoznik <mprivozn@redhat.com>
      f1e8d2f0
  21. 05 10月, 2018 1 次提交
    • P
      util: introduce cgroup v2 files · b4ddf5ae
      Pavel Hrdina 提交于
      Place cgroup v2 backend type before cgroup v1 to make it obvious
      that cgroup v2 is preferred implementation.
      
      Following patches will introduce support for hybrid configuration
      which will allow us to use both at the same time, but we should
      prefer cgroup v2 regardless.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      b4ddf5ae
  22. 25 9月, 2018 2 次提交