1. 21 12月, 2012 9 次提交
  2. 19 12月, 2012 2 次提交
  3. 18 12月, 2012 2 次提交
    • D
      Add support for <hostdev mode="capabilities"> · aae0fc2a
      Daniel P. Berrange 提交于
      The <hostdev> device type has long had a redundant "mode"
      attribute, which has always been "subsys". This finally
      introduces a new mode "capabilities", which will be used
      by the LXC driver for device assignment. Since container
      based virtualization uses a single kernel, the idea of
      assigning physical PCI devices doesn't make sense. It is
      still reasonable to assign USB devices, but for assigning
      arbitrary nodes in /dev, the new 'capabilities' mode is
      to be used.
      
      The first capability support is 'storage', which is for
      assignment of block devices. Functionally this is really
      pretty similar to the <disk> support. The only difference
      is the device node name is identical in both host and
      container namespaces.
      
          <hostdev mode='capabilities' type='storage'>
            <source>
              <block>/dev/sdf1</block>
            </source>
          </hostdev>
      
      The second capability support is 'misc', which is for
      assignment of character devices. There is no existing
      parallel to this. Again the device node is the same
      inside & outside the container.
      
          <hostdev mode='capabilities' type='misc'>
            <source>
              <char>/dev/input/event3</char>
            </source>
          </hostdev>
      
      The reason for keeping the char & storage devices
      separate in the domain XML, is to mirror the split
      in the node device XML. NB the node device XML does
      not yet report character devices, but that's another
      new patch to come
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      aae0fc2a
    • V
      tests: Add tests for sysinfo · 347a712a
      Viktor Mihajlovski 提交于
      Test cases for virSysinfoRead. Initially, there are tests for
      x86 (DMI based) and s390 (/proc/... based).
      In lack of PPC data, I have stubbed out the test for it, but it
      can be added with a minimal effort.
      Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
      347a712a
  4. 17 12月, 2012 3 次提交
    • G
      tests: add one -device video device testcase · ed6fc41b
      Guannan Ren 提交于
      The testcase is for testing non-fixed PCI address for primary
      video device and using video args to -deivce qemu option.
      ed6fc41b
    • G
      qemu: use newer -device video device in qemu commandline · aa51202b
      Guannan Ren 提交于
      '-device VGA' maps to '-vga std'
      '-device cirrus-vga' maps to '-vga cirrus'
      '-device qxl-vga' maps to '-vga qxl'
                   (there is also '-device qxl' for secondary devices)
      '-device vmware-svga' maps to '-vga vmware'
      
      For qemu(>=1.2), we can use -device to replace -vga for video
      device. For the primary video device, the patch tries to use 0x2
      slot for matching old qemu. If the 0x2 slot is allocated already,
      the addr property could help for using any available slot.
      For qemu(< 1.2), we keep using -vga for primary device.
      aa51202b
    • G
      qemu: add qemu vga devices caps and one cap to mark them usable · 4c993d8a
      Guannan Ren 提交于
      QEMU_CAPS_DEVICE_QXL          -device qxl
      QEMU_CAPS_DEVICE_VGA          -device VGA
      QEMU_CAPS_DEVICE_CIRRUS_VGA   -device cirrus-vga
      QEMU_CAPS_DEVICE_VMWARE_SVGA  -device vmware-svga
      
      QEMU_CAPS_DEVICE_VIDEO_PRIMARY  /* safe to use -device XXX
                                       for primary video device */
      
      Fix a typo in qemuCapsObjectTypes, the string 'qxl' here
      should be -device qxl rather than -vga [...|qxl|..]
      4c993d8a
  5. 14 12月, 2012 1 次提交
    • L
      network: prevent dnsmasq from listening on localhost · d66eb786
      Laine Stump 提交于
      This patch resolves the problem reported in:
      
         https://bugzilla.redhat.com/show_bug.cgi?id=886663
      
      The source of the problem was the fix for CVE 2011-3411:
      
         https://bugzilla.redhat.com/show_bug.cgi?id=833033
      
      which was originally committed upstream in commit
      753ff83a. That commit improperly
      removed the "--except-interface lo" from dnsmasq commandlines when
      --bind-dynamic was used (based on comments in the latter bug).
      
      It turns out that the problem reported in the CVE could be eliminated
      without removing "--except-interface lo", and removing it actually
      caused each instance of dnsmasq to listen on localhost on port 53,
      which created a new problem:
      
      If another instance of dnsmasq using "bind-interfaces" (instead of
      "bind-dynamic") had already been started (or if another instance
      started later used "bind-dynamic"), this wouldn't have any immediately
      visible ill effects, but if you tried to start another dnsmasq
      instance using "bind-interfaces" *after* starting any libvirt
      networks, the new dnsmasq would fail to start, because there was
      already another process listening on port 53.
      
      (Subsequent to the CVE fix, another patch changed the network driver
      to put dnsmasq options in a conf file rather than directly on the
      dnsmasq commandline, but preserved the same options.)
      
      This patch changes the network driver to *always* add
      "except-interface=lo" to dnsmasq conf files, regardless of whether we use
      bind-dynamic or bind-interfaces. This way no libvirt dnsmasq instances
      are listening on localhost (and the CVE is still fixed).
      
      The actual code change is miniscule, but must be propogated through all
      of the test files as well.
      d66eb786
  6. 13 12月, 2012 1 次提交
    • E
      network: match xml warning message · 7339bc4c
      Eric Blake 提交于
      I noticed that /var/lib/libvirt/dnsmasq/*.conf used the wrong word;
      it was intended to match the wording in src/util/xml.c.
      
      * src/network/bridge_driver.c (networkDnsmasqConfContents): Fix typo.
      * tests/networkxml2confdata/*.conf: Update accordingly.
      7339bc4c
  7. 12 12月, 2012 2 次提交
  8. 11 12月, 2012 2 次提交
    • G
      network: put dnsmasq parameters in conf-file instead of command line · 8b32c80d
      Gene Czarcinski 提交于
      This patch changes how parameters are passed to dnsmasq.  Instead of
      being on the command line, the parameters are put into a file (one
      parameter per line) and a commandline --conf-file= specifies the
      location of the file.  The file is located in the same directory as
      the leases file.
      
      Putting the dnsmasq parameters into a configuration file
      allows them to be examined and more easily understood than
      examining the command lines displayed by "ps ax".  This is
      especially true when a number of networks have been started.
      
      When the use of dnsmasq was originally done, the required command line
      was simple, but it has gotten more complicated over time and will
      likely become even more complicated in the future.
      
      Note: The test conf files have all been renamed .conf instead of
      .argv, and tests/networkxml2xmlargvdata was moved to
      tests/networkxml2xmlconfdata.
      8b32c80d
    • G
      network: add support for DHCPv6 · 2d5cd1d7
      Gene Czarcinski 提交于
      The DHCPv6 support includes IPV6 dhcp-range and dhcp-host for one
      IPv6 subnetwork on one interface.  This support will only work
      if dnsmasq version >= 2.64; otherwise an error occurs if
      dhcp-range or dhcp-host is specified for an IPv6 address.
      
      Essentially, this change provides the same DHCP support for IPv6
      that has been available for IPv4.
      
      With dnsmasq >= 2.64, support for the RA service is also now provided
      by dnsmasq (radvd is no longer used/started). (Although at least one
      version of dnsmasq prior to 2.64 "supported" IPv6 Router
      Advertisement, there were bugs (fixed in 2.64) that rendered it
      unusable.)
      
      Documentation and the network schema has been updated
      to reflect the new support.
      2d5cd1d7
  9. 07 12月, 2012 1 次提交
  10. 06 12月, 2012 1 次提交
    • G
      network: allow guest to guest IPv6 without gateway definition · 705e67d4
      Gene Czarcinski 提交于
      This patch adds the capability for virtual guests to do IPv6
      communication via a virtual network interface with no IPv6 (gateway)
      addresses specified.  This capability has always been enabled by
      default for IPv4, but disabled for IPv6 for security concerns, and
      because it requires the ip6tables command to be operational (which
      isn't the case on a system with the ipv6 module completely disabled).
      
      This patch adds a new attribute "ipv6" at the toplevel of a <network>
      object.  If ipv6='yes', the extra ip6tables rules required to permite
      inter-guest communications are added when the network is started. If
      it is 'no', or not present, those rules will not be added; thus the
      default behavior doesn't change, so there should be no compatibility
      issues with any existing installations.
      
      Note that virtual guests cannot communication with the virtualization
      host via this interface, because the following kernel tunable has
      been set:
      
         net.ipv6.conf.<bridge_interface_name>.disable_ipv6 = 1
      
      This assures that the bridge interface will not have an IPv6
      link-local (fe80::) address.
      
      To control this behavior so that it is not enabled by default, the parameter
      ipv6='yes' on the <network> statement has been added.
      
      Documentation related to this patch has been updated.
      The network schema has also been updated.
      705e67d4
  11. 01 12月, 2012 1 次提交
  12. 30 11月, 2012 2 次提交
    • L
      network: use dnsmasq --bind-dynamic when available · 753ff83a
      Laine Stump 提交于
      This bug resolves CVE-2012-3411, which is described in the following
      bugzilla report:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=833033
      
      The following report is specifically for libvirt on Fedora:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=874702
      
      In short, a dnsmasq instance run with the intention of listening for
      DHCP/DNS requests only on a libvirt virtual network (which is
      constructed using a Linux host bridge) would also answer queries sent
      from outside the virtualization host.
      
      This patch takes advantage of a new dnsmasq option "--bind-dynamic",
      which will cause the listening socket to be setup such that it will
      only receive those requests that actually come in via the bridge
      interface. In order for this behavior to actually occur, not only must
      "--bind-interfaces" be replaced with "--bind-dynamic", but also all
      "--listen-address" options must be replaced with a single
      "--interface" option. Fully:
      
         --bind-interfaces --except-interface lo --listen-address x.x.x.x ...
      
      (with --listen-address possibly repeated) is replaced with:
      
         --bind-dynamic --interface virbrX
      
      Of course libvirt can't use this new option if the host's dnsmasq
      doesn't have it, but we still want libvirt to function (because the
      great majority of libvirt installations, which only have mode='nat'
      networks using RFC1918 private address ranges (e.g. 192.168.122.0/24),
      are immune to this vulnerability from anywhere beyond the local subnet
      of the host), so we use the new dnsmasqCaps API to check if dnsmasq
      supports the new option and, if not, we use the "old" option style
      instead. In order to assure that this permissiveness doesn't lead to a
      vulnerable system, we do check for non-private addresses in this case,
      and refuse to start the network if both a) we are using the old-style
      options, and b) the network has a publicly routable IP
      address. Hopefully this will provide the proper balance of not being
      disruptive to those not practically affected, and making sure that
      those who *are* affected get their dnsmasq upgraded.
      
      (--bind-dynamic was added to dnsmasq in upstream commit
      54dd393f3938fc0c19088fbd319b95e37d81a2b0, which was included in
      dnsmasq-2.63)
      753ff83a
    • L
      util: capabilities detection for dnsmasq · 719c2c76
      Laine Stump 提交于
      In order to optionally take advantage of new features in dnsmasq when
      the host's version of dnsmasq supports them, but still be able to run
      on hosts that don't support the new features, we need to be able to
      detect the version of dnsmasq running on the host, and possibly
      determine from the help output what options are in this dnsmasq.
      
      This patch implements a greatly simplified version of the capabilities
      code we already have for qemu. A dnsmasqCaps device can be created and
      populated either from running a program on disk, reading a file with
      the concatenated output of "dnsmasq --version; dnsmasq --help", or
      examining a buffer in memory that contains the concatenated output of
      those two commands. Simple functions to retrieve capabilities flags,
      the version number, and the path of the binary are also included.
      
      bridge_driver.c creates a single dnsmasqCaps object at driver startup,
      and disposes of it at driver shutdown. Any time it must be used, the
      dnsmasqCapsRefresh method is called - it checks the mtime of the
      binary, and re-runs the checks if the binary has changed.
      
      networkxml2argvtest.c creates 2 "artificial" dnsmasqCaps objects at
      startup - one "restricted" (doesn't support --bind-dynamic) and one
      "full" (does support --bind-dynamic). Some of the test cases use one
      and some the other, to make sure both code pathes are tested.
      719c2c76
  13. 29 11月, 2012 1 次提交
  14. 28 11月, 2012 1 次提交
  15. 27 11月, 2012 1 次提交
  16. 26 11月, 2012 1 次提交
    • J
      build: fix build --without-network · 5efacd78
      Ján Tomko 提交于
      bridge_driver.h: silence gcc warnings:
      statement with no effect [-Wunused-value]
      unused variable 'net' [-Wunused-variable]
      
      virdrivermoduletest.c: don't require network driver module
      if it hasn't been built.
      5efacd78
  17. 23 11月, 2012 1 次提交
    • M
      qemuhelpdata: Revert my 'fix' · a154f5f3
      Michal Privoznik 提交于
      I was convicted that space at EOL should no be there
      even for qemu help data. Hence, I've removed one in
      commit bb2f6216. However, it turns out we want
      it exactly the way qemu produces it. So I should undo
      my premature fix. A patch against qemu has been posted
      as well.
      a154f5f3
  18. 22 11月, 2012 2 次提交
    • J
      tests: update qemuhelptest data · bb2f6216
      Ján Tomko 提交于
      Both generated with
      qemu-system-x86_64 --help > qemu-1.2.0
      
      qemu-system-x86_64 \
      -device ? \
      -device pci-assign,? \
      -device virtio-blk-pci,? \
      -device virtio-net-pci,? \
      -device scsi-disk,? \
      -device PIIX4_PM,? \
      -device usb-redir,? \
      -device ide-drive,? \
      -device usb-host,? 2> qemu-1.2.0-device
      
      It seems I missed a few -device flags when doing this last time and I
      mixed up qemu and qemu-kvm.
      bb2f6216
    • J
      c5834ec1
  19. 15 11月, 2012 1 次提交
  20. 13 11月, 2012 4 次提交
  21. 10 11月, 2012 1 次提交
    • V
      capabilities: defaultConsoleTargetType can depend on architecture · b1c88c14
      Viktor Mihajlovski 提交于
      For S390, the default console target type cannot be of type 'serial'.
      It is necessary to at least interpret the 'arch' attribute
      value of the os/type element to produce the correct default type.
      
      Therefore we need to extend the signature of defaultConsoleTargetType
      to account for architecture. As a consequence all the drivers
      supporting this capability function must be updated.
      
      Despite the amount of changed files, the only change in behavior is
      that for S390 the default console target type will be 'virtio'.
      
      N.B.: A more future-proof approach could be to to use hypervisor
      specific capabilities to determine the best possible console type.
      For instance one could add an opaque private data pointer to the
      virCaps structure (in case of QEMU to hold capsCache) which could
      then be passed to the defaultConsoleTargetType callback to determine
      the console target type.
      Seems to be however a bit overengineered for the use case...
      Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
      b1c88c14