1. 25 9月, 2013 6 次提交
    • L
      bridge driver: don't masquerade local subnet broadcast/multicast packets · 51e184e9
      Laszlo Ersek 提交于
      Packets sent by guests on virbrN, *or* by dnsmasq on the same, to
      - 255.255.255.255/32 (netmask-independent local network broadcast
        address), or to
      - 224.0.0.0/24 (local subnetwork multicast range)
      are never forwarded, hence it is not necessary to masquerade them.
      
      In fact we must not masquerade them: translating their source addresses or
      source ports (where applicable) may confuse receivers on virbrN.
      
      One example is the DHCP client in OVMF (= UEFI firmware for virtual
      machines):
      
        http://thread.gmane.org/gmane.comp.bios.tianocore.devel/1506/focus=2640
      
      It expects DHCP replies to arrive from remote source port 67. Even though
      dnsmasq conforms to that, the destination address (255.255.255.255) and
      the source address (eg. 192.168.122.1) in the reply allow the UDP
      masquerading rule to match, which rewrites the source port to or above
      1024. This prevents the DHCP client in OVMF from accepting the packet.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=709418Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      51e184e9
    • L
      util/viriptables: add/remove rules that short-circuit masquerading · ccca5dc3
      Laszlo Ersek 提交于
      The functions
      - iptablesAddForwardDontMasquerade(),
      - iptablesRemoveForwardDontMasquerade
      handle exceptions in the masquerading implemented in the POSTROUTING chain
      of the "nat" table. Such exceptions should be added as chronologically
      latest, logically top-most rules.
      
      The bridge driver will call these functions beginning with the next patch:
      some special destination IP addresses always refer to the local
      subnetwork, even though they don't match any practical subnetwork's
      netmask. Packets from virbrN targeting such IP addresses are never routed
      outwards, but the current rules treat them as non-virbrN-destined packets
      and masquerade them. This causes problems for some receivers on virbrN.
      Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      ccca5dc3
    • P
      qemu: Wire up better early error reporting · ef29de14
      Peter Krempa 提交于
      The previous patches added infrastructure to report better errors from
      monitor in some cases. This patch finalizes this "feature" by enabling
      this enhanced error reporting on early phases of VM startup. In these
      phases the possibility of qemu producing a useful error message is
      really high compared to running it during the whole life cycle. After
      the start up is complete, the feature is disabled to provide the usual
      error messages so that users are not confused by possibly irrelevant
      messages that may be in the domain log.
      
      The original motivation to do this enhancement is to capture errors when
      using VFIO device passthrough, where qemu reports errors after the
      monitor is initialized and the existing error catching code couldn't
      catch this producing a unhelpful message:
      
       # virsh start test
       error: Failed to start domain test
       error: Unable to read from monitor: Connection reset by peer
      
      With this change, the message is changed to:
      
       # virsh start test
       error: Failed to start domain test
       error: internal error: early end of file from monitor: possible problem:
       qemu-system-x86_64: -device vfio-pci,host=00:1a.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: error, group 8 is not viable, please ensure all devices within the iommu_group are bound to their vfio bus driver.
       qemu-system-x86_64: -device vfio-pci,host=00:1a.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to get group 8
       qemu-system-x86_64: -device vfio-pci,host=00:1a.0,id=hostdev0,bus=pci.0,addr=0x5: Device 'vfio-pci' could not be initialized
      ef29de14
    • P
      qemu: monitor: Produce better errors on monitor hangup · 90139a62
      Peter Krempa 提交于
      Change the monitor error code to add the ability to access the qemu log
      file using a file descriptor so that we can dig in it for a more useful
      error message. The error is now logged on monitor hangups and overwrites
      a possible lesser error. A hangup on the monitor usualy means that qemu
      has crashed and there's a significant chance it produced a useful error
      message.
      
      The functionality will be latent until the next patch.
      90139a62
    • P
      qemu: monitor: Add infrastructure to access VM logs for better err msgs · 8519e9ec
      Peter Krempa 提交于
      Early VM startup errors usually produce a better error message in the
      machine log file. Currently we were accessing it only when the process
      exited during certain phases of startup. This will help adding a more
      comprehensive error extraction for early qemu startup phases.
      
      This patch adds infrastructure to keep a file descriptor for the machine
      log file that will be used in case an error happens.
      8519e9ec
    • P
      qemu_process: Make qemuProcessReadLog() more versatile and reusable · 310651a5
      Peter Krempa 提交于
      Teach the function to skip character device definitions printed by qemu
      at startup in addition to libvirt log messages and make it usable from
      outside of qemu_process.c. Also add documentation about the func.
      310651a5
  2. 24 9月, 2013 29 次提交
  3. 23 9月, 2013 4 次提交
  4. 21 9月, 2013 1 次提交