1. 10 12月, 2014 10 次提交
  2. 09 12月, 2014 23 次提交
    • J
      security: Manage SELinux labels on shared/readonly hostdev's · f36d9285
      John Ferlan 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1082521
      
      Support for shared hostdev's was added in a number of commits, initially
      starting with 'f2c1d9a8' and most recently commit id 'fd243fc4' to fix
      issues with the initial implementation.  Missed in all those changes was
      the need to mimic the virSELinux{Set|Restore}SecurityDiskLabel code to
      handle the "shared" (or shareable) and readonly options when Setting
      or Restoring the SELinux labels.
      
      This patch will adjust the virSecuritySELinuxSetSecuritySCSILabel to not
      use the virSecuritySELinuxSetSecurityHostdevLabelHelper in order to set
      the label. Rather follow what the Disk code does by setting the label
      differently based on whether shareable/readonly is set.  This patch will
      also modify the virSecuritySELinuxRestoreSecuritySCSILabel to follow
      the same logic as virSecuritySELinuxRestoreSecurityImageLabelInt and not
      restore the label if shared/readonly
      f36d9285
    • J
      tests: Fix sharable typo · 048237e3
      John Ferlan 提交于
      048237e3
    • L
      conf: forbid negative number in address(like controller, bus, slot...) · a23fefdf
      Luyao Huang 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1171582
      
      When we edit a negative controller address number to a device,
      some of them will auto generate a controller with invalid index
      number. This will make guest disappear after restart libvirtd.
      Instead of allowing negative number for controller index, we
      should forbid negative number in these place (we did this before,
      but after f18c02ec, virStrToLong_ui changed to allow negative
      number). Therefore switch to virStrToLong_uip in these places.
      Signed-off-by: NLuyao Huang <lhuang@redhat.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      a23fefdf
    • P
      qemu: migration: Unlock vm on failed ACL check in protocol v2 APIs · 2bdcd29c
      Peter Krempa 提交于
      Avoid leaving the domain locked on a failed ACL check in
      qemuDomainMigratePerform() and qemuDomainMigrateFinish2().
      
      Introduced in commit abf75aea (Add ACL checks into the QEMU driver).
      2bdcd29c
    • M
      docs: Fix simple typo s/ a API/ an API/ · 77a778d2
      Martin Kletzander 提交于
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      77a778d2
    • M
      build: Move check for XML::XPath into bootstrap · e9e5eee5
      Martin Kletzander 提交于
      The module XML::XPath is needed when building from git only (no need to
      have it when building from tarball), so this patch moves the check from
      specfile into bootstrap.conf.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      e9e5eee5
    • E
      maint: update to latest gnulib · 8a408b86
      Eric Blake 提交于
      Several portability changes, but the one we are most interested in
      is the improvement to bootstrap to detect perl modules.
      
      This patch doesn't actually change our bootstrap requirements
      (that will be a separate patch), but sets the stage for it.
      
      * .gnulib: Update to latest.
      * bootstrap: Regenerate from upstream.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      8a408b86
    • E
      build: fix mingw printing of pid · 1398b700
      Eric Blake 提交于
      Commit c7542573 introduced a compilation failure:
      
      ../../src/access/viraccessdriverpolkit.c: In function 'virAccessDriverPolkitCheck':
      ../../src/access/viraccessdriverpolkit.c:137:5: error: format '%d' expects argument of type 'int', but argument 9 has type 'pid_t' [-Werror=format=]
           VIR_DEBUG("Check action '%s' for process '%d' time %lld uid %d",
           ^
      
      Since mingw pid_t is 64 bits, it's easier to just follow what we've
      done elsewhere and cast to a large enough type when printing pids.
      
      * src/access/viraccessdriverpolkit.c (virAccessDriverPolkitCheck):
      Add cast.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      1398b700
    • E
      build: fix unused variable in mingw · b4861ce9
      Eric Blake 提交于
      Bug introduced in commit 100b7a72:
      
      util/virnetdevbridge.c: In function 'virNetDevBridgePortSetLearning':
      util/virnetdevbridge.c:359:38: error: unused parameter 'enable' [-Werror=unused-parameter]
                                      bool enable)
                                            ^
      
      * src/util/virnetdevbridge.c (virNetDevBridgePortSetLearning): Mark
      unused variable.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      b4861ce9
    • K
      network: don't allow multiple dhcp sections · 5adc6031
      Kyle DeFrancia 提交于
      This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=907779
      
      A <dhcp> element can exist in only one IPv4 address and one IPv6
      address per network.  This patch enforces that in virNetworkUpdate.
      5adc6031
    • L
      lxc: always use virDomainNetGetActualBridgeName to get interface's bridge · b0fbe745
      Laine Stump 提交于
      lxcProcessSetupInterfaces() used to have a special case for
      actualType='network' (a network with forward mode of route, nat, or
      isolated) to call the libvirt public API to retrieve the bridge being
      used by a network. That is no longer necessary - since all network
      types that use a bridge and tap device now get the bridge name stored
      in the ActualNetDef, we can just always use
      virDomainNetGetActualBridgeName() instead.
      b0fbe745
    • L
      qemu: always use virDomainNetGetActualBridgeName to get interface's bridge · 4aae2ed6
      Laine Stump 提交于
      qemuNetworkIfaceConnect() used to have a special case for
      actualType='network' (a network with forward mode of route, nat, or
      isolated) to call the libvirt public API to retrieve the bridge being
      used by a network. That is no longer necessary - since all network
      types that use a bridge and tap device now get the bridge name stored
      in the ActualNetDef, we can just always use
      virDomainNetGetActualBridgeName() instead.
      
      (an audit of the two callers to qemuNetworkIfaceConnect() confirms
      that it is never called for any other type of network, so the dead
      code in the else statement (logging an internal error if it is called
      for any other type of network) is eliminated in the process.)
      4aae2ed6
    • L
      qemu: setup tap devices for macTableManager='libvirt' · 7cb822c2
      Laine Stump 提交于
      When libvirt is managing the MAC table of a Linux host bridge, it must
      turn off learning and unicast_flood for each tap device attached to
      that bridge, then add a Forwarding Database (fdb) entry for the tap
      device using the MAC address from the domain interface config.
      
      Once we have disabled learning and flooding, any packet that has a
      destination MAC address not present in the fdb will be dropped by the
      bridge. This, along with the opportunistic disabling of promiscuous
      mode[*], can result in enhanced network performance. and a potential
      slight security improvement.
      
      [*] If there is only one device on the bridge with learning/unicast_flood
      enabled, then that device will automatically have promiscuous mode
      disabled. If there are *no* devices with learning/unicast_flood
      enabled (e.g. for a libvirt "route", "nat", or isolated network that
      has no physical device attached), then all non-tap devices will have
      promiscuous mode disabled (tap devices always have promiscuous mode
      enabled, which may be a bug in the kernel, but in practice has 0
      effect).
      
      None of this has any effect for kernels prior to 3.15 (upstream kernel
      commit 2796d0c648c940b4796f84384fbcfb0a2399db84 "bridge: Automatically
      manage port promiscuous mode"). Even after that, until kernel 3.17
      (upstream commit 5be5a2df40f005ea7fb7e280e87bbbcfcf1c2fc0 "bridge: Add
      filtering support for default_pvid") traffic will not be properly
      forwarded without manually adding vlan table entries. Unfortunately,
      although the presence of the first patch is signalled by existence of
      the "learning" and "unicast_flood" options in sysfs, there is no
      reliable way to query whether or not the system's kernel has the
      second of those patches installed, the only thing that can be done is
      to try the setting and see if traffic continues to pass.
      7cb822c2
    • L
      network: setup bridge devices for macTableManager='libvirt' · 8a144c90
      Laine Stump 提交于
      When the bridge device for a network has macTableManager='libvirt' the
      intent is that all kernel management of the bridge's MAC table
      (Forwarding Database, or fdb, in the case of a Linux Host Bridge) be
      disabled, with libvirt handling updates to the table instead. The
      setup required for the bridge itself is:
      
      1) set the "vlan_filtering" property of the bridge device to 1.
      
      2) If the bridge has a "Dummy" tap device used to set a fixed MAC
      address on the bridge (which is always the case for a bridge created
      by libvirt, and never the case for a bridge created by the host system
      network config), turn off learning and unicast_flood on this tap (this
      is needed even though this tap is never IFF_UP, because the kernel
      ignores the IFF_UP flag of devices when using their settings to
      automatically decide whether or not to turn off promiscuous mode for
      any attached device).
      
      (1) is done both for libvirt-created/managed bridges, and for bridges
      that are created by the host system config, while (2) is done only for
      bridges created by libvirt (i.e. for forward modes of nat, routed, and
      isolated bridges)
      
      There is no attempt to turn vlan_filtering off when destroying the
      network because in the case of a libvirt-created bridge, the bridge is
      about to be destroyed anyway, and in the case of a system bridge, if
      the other devices attached to the bridge could operate properly before
      destroying libvirt's network object, they will continue to operate
      properly (this is similar to the way that libvirt will enable
      ip_forwarding whenever a routed/natted network is started, but will
      never attempt to disable it if they are stopped).
      8a144c90
    • L
      network: store network macTableManager setting in NetDef actual object · 33f4a8bc
      Laine Stump 提交于
      At the time that the network driver allocates a connection to a
      network, the tap device that will be used hasn't yet been created -
      that will be done later by qemu (or lxc or whoever) - but if the
      network has macTableManager='libvirt', then when we do get around to
      creating the tap device, we will need to add an entry for it to the
      network bridge's fdb (forwarding database) *and* turn off learning and
      unicast_flood for that tap device in the bridge's sysfs settings. This
      means that qemu needs to know both the bridge name as well as the
      setting of macTableManager, so we either need to create a new API to
      retrieve that info, or just pass it back in the ActualNetDef that is
      created during networkAllocateActualDevice. We choose the latter
      method, since it's already done for the bridge device, and it has the
      side effect of making the information available in domain status.
      
      (NB: in the future, I think that the tap device should actually be
      created by networkAllocateActualDevice(), as that will solve several
      other problems, but that is a battle for another day, and this
      information will still be useful outside the network driver)
      33f4a8bc
    • L
      network: save bridge name in ActualNetDef when actualType==network too · a3609121
      Laine Stump 提交于
      When the actualType of a virDomainNetDef is "network", it means that
      we are connecting to a libvirt-managed network (routed, natted, or
      isolated) which does use a bridge device (created by libvirt). In the
      past we have required drivers such as qemu to call the public API to
      retrieve the bridge name in this case (even though it is available in
      the NetDef's ActualNetDef if the actualType is "bridge" (i.e., an
      externally-created bridge that isn't managed by libvirt). There is no
      real reason for this difference, and as a matter of fact it
      complicates things for qemu. Also, there is another bridge-related
      attribute (macTableManager) that will need to be available in both
      cases, so this makes things consistent.
      
      In order to avoid problems when restarting libvirtd after an update
      from an older version that *doesn't* store the network's bridgename in
      the ActualNetDef, we also need to put it in place during
      networkNotifyActualDevice() (this function is run for each interface
      of each domain whenever libvirtd is restarted).
      
      Along with making the bridge name available in the internal object, it
      is also now reported in the <source> element of the <interface> state
      XML (or the <actual> subelement in the internally-stored format).
      
      The one oddity about this change is that usually there is a separate
      union for every different "type" in a higher level object (e.g. in the
      case of a virDomainNetDef there are separate "network" and "bridge"
      members of the union that pivots on the type), but in this case
      network and bridge types both have exactly the same attributes, so the
      "bridge" member is used for both type==network and type==bridge.
      a3609121
    • L
      conf: new network bridge device attribute macTableManager · 40961978
      Laine Stump 提交于
      The macTableManager attribute of a network's bridge subelement tells
      libvirt how the bridge's MAC address table (used to determine the
      egress port for packets) is managed. In the default mode, "kernel",
      management is left to the kernel, which usually determines entries in
      part by turning on promiscuous mode on all ports of the bridge,
      flooding packets to all ports when the correct destination is unknown,
      and adding/removing entries to the fdb as it sees incoming traffic
      from particular MAC addresses.  In "libvirt" mode, libvirt turns off
      learning and flooding on all the bridge ports connected to guest
      domain interfaces, and adds/removes entries according to the MAC
      addresses in the domain interface configurations. A side effect of
      turning off learning and unicast_flood on the ports of a bridge is
      that (with Linux kernel 3.17 and newer), the kernel can automatically
      turn off promiscuous mode on one or more of the bridge's ports
      (usually only the one interface that is used to connect the bridge to
      the physical network). The result is better performance (because
      packets aren't being flooded to all ports, and can be dropped earlier
      when they are of no interest) and slightly better security (a guest
      can still send out packets with a spoofed source MAC address, but will
      only receive traffic intended for the guest interface's configured MAC
      address).
      
      The attribute looks like this in the configuration:
      
        <network>
          <name>test</name>
          <bridge name='br0' macTableManager='libvirt'/>
          ...
      
      This patch only adds the config knob, documentation, and test
      cases. The functionality behind this knob is added in later patches.
      40961978
    • L
      util: functions to manage bridge fdb (forwarding database) · 19a5474d
      Laine Stump 提交于
      These two functions use netlink RTM_NEWNEIGH and RTM_DELNEIGH messages
      to add and delete entries from a bridge's fdb. The bridge itself is
      not referenced in the arguments to the functions, only the name of the
      device that is attached to the bridge (since a device can only be
      attached to one bridge at a time, and must be attached for this
      function to make sense, the kernel easily infers which bridge's fdb is
      being modified by looking at the device name/index).
      19a5474d
    • L
      util: new functions for setting bridge and bridge port attributes · 100b7a72
      Laine Stump 提交于
      These functions all set/get items in the sysfs for a bridge device.
      100b7a72
    • E
      getstats: add block.n.path stat · 7b499262
      Eric Blake 提交于
      I'm about to make block stats optionally more complex to cover
      backing chains, where block.count will no longer equal the number
      of <disks> for a domain.  For these reasons, it is nicer if the
      statistics output includes the source path (for local files).
      This patch doesn't add anything for network disks, although we
      may decide to add that later.
      
      With this patch, I now see the following for the same domain as
      in the previous patch (one qcow2 file, and an empty cdrom drive):
      $ virsh domstats --block foo
      Domain: 'foo'
        block.count=2
        block.0.name=hda
        block.0.path=/var/lib/libvirt/images/foo.qcow2
        block.1.name=hdc
      
      * src/libvirt-domain.c (virConnectGetAllDomainStats): Document
      new field.
      * tools/virsh.pod (domstats): Document new field.
      * src/qemu/qemu_driver.c (qemuDomainGetStatsBlock): Return the new
      stat for local files/block devices.
      (QEMU_ADD_NAME_PARAM): Add parameter.
      (qemuDomainGetStatsInterface): Update caller.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      7b499262
    • E
      getstats: start giving offline block stats · 56b21dfe
      Eric Blake 提交于
      I noticed that for an offline domain, 'virsh domstats --block $dom'
      was producing just the domain name, with no stats.  But the older
      'virsh domblkinfo' works just fine on offline domains.  This patch
      starts to get us closer, by at least reporting the disk names for
      an offline domain.
      
      With this patch, I now see the following for an offline domain
      with one qcow2 disk and an empty cdrom drive:
      $ virsh domstats --block foo
      Domain: 'foo'
        block.count=2
        block.0.name=hda
        block.1.name=hdc
      
      * src/qemu/qemu_driver.c (qemuDomainGetStatsBlock): Don't short-circuit
      output of block name.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      56b21dfe
    • E
      getstats: improve documentation · f301fe77
      Eric Blake 提交于
      At least with 'virsh domstats --block' on an offline domain, we
      currently output no stats even though we recognize the stat
      category.  Although a later patch will improve this situation,
      it is better to document that this is expected behavior.
      
      Also, while the current implementation rejects filtering flags
      for virDomainListGetStats, this limitation may be lifted in the
      future and we do not enforce it at the API level.
      
      * src/libvirt-domain.c (virConnectGetAllDomainStats): Document
      that recognized stats might not be reported.
      (virDomainListGetStats): Likewise, and tweak filtering documentation.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      f301fe77
    • E
      getstats: avoid memory leak on OOM · 2f61602e
      Eric Blake 提交于
      qemuDomainGetStatsBlock() could leak a stats hash table if it
      encountered OOM while populating the virTypedParameters.
      Oddly, the fix doesn't even touch qemuDomainGetStatsBlock :)
      
      * src/qemu/qemu_driver.c (QEMU_ADD_COUNT_PARAM)
      (QEMU_ADD_NAME_PARAM): Don't return early.
      (qemuDomainGetStatsInterface): Adjust caller.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      2f61602e
  3. 08 12月, 2014 4 次提交
  4. 06 12月, 2014 3 次提交