1. 02 7月, 2015 1 次提交
  2. 01 7月, 2015 14 次提交
    • M
      lxc: Don't pass a local variable address randomly · 302146b1
      Michal Privoznik 提交于
      So, recently I was testing the LXC driver. You know, startup some
      domains. But to my surprise, I was not able to start a single one:
      
        virsh # start --console test
        error: Reconnected to the hypervisor
        error: Failed to start domain test
        error: internal error: guest failed to start: unexpected exit status 125
      
      So I've start digging. It turns out, that in virExec(), when I printed
      out the @cmd, I got strange values: *(cmd->outfdptr) was certainly not
      valid FD number: it has random value of several millions. This
      obviously made prepareStdFd(childout, STDOUT_FILENO) fail (line 611).
      But outfdptr is set in virCommandSetOutputFD(). The only place within
      LXC driver where the function is called is in
      virLXCProcessBuildControllerCmd(). If you take a closer look at the
      function it looks like this:
      
      static virCommandPtr
      virLXCProcessBuildControllerCmd(virLXCDriverPtr driver,
                                      ..
                                      int logfd,
                                      const char *pidfile)
      {
          ...
          virCommandSetOutputFD(cmd, &logfd);
          virCommandSetErrorFD(cmd, &logfd);
          ...
      }
      
      Yes, you guessed it. @logfd is passed into the function by value.
      However, in the function we try to get its address (an address of a
      local variable) which is no longer valid once function is finished and
      stack is cleaned. Therefore when cmd->outfdptr is evaluated at any
      point after this function, we may get a random number, depending on
      what's currently on the stack. Of course, this may work sometimes too
      - it depends on the compiler how it arranges the code, when the stack
      is wiped out.
      
      In order to fix this, lets pass a pointer to @logfd instead of
      figuring out (wrong) its value in a function.
      
      The bug was introduced in e1de5521.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      302146b1
    • J
      qemu: Resolve Coverity DEADCODE · ebd62eba
      John Ferlan 提交于
      Commit id 'f967e7a6' didn't place the closing parentheses quite right
      causing DEADCODE errors since the rc setting/comparison was wrong.
      ebd62eba
    • P
      conf: qemu: Taint VMs using custom device tree blob · 4b48ba4a
      Peter Krempa 提交于
      Using a custom device tree image may cause unexpected behavior in
      architectures that use this approach to detect platform devices. Since
      usually the device tree is generated by qemu and thus it's not normally
      used let's taint VMs using it to make it obvious as a possible source of
      problems.
      4b48ba4a
    • P
      qemu: Audit memory size with memory hotplug operations · 91081979
      Peter Krempa 提交于
      The memory device hot(un)plug was missing calls to the auditing code.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1226234
      91081979
    • P
      conf: audit: Audit physical memory size rather than balloon request · 1a136774
      Peter Krempa 提交于
      Since the balloon driver does not guarantee that it returns memory to
      the host, using the value in the audit message is not a good idea.
      
      This patch removes auditing from updating the balloon size and reports
      the total physical size at startup.
      1a136774
    • J
      qemu: Avoid using ".(null)" in UNIX socket path · ffbafd4e
      Jiri Denemark 提交于
      The code which generates paths for UNIX socket blindly used target name
      without checking if it was set. Thus for the following device XML
      
          <channel type='unix'>
            <source mode='bind'/>
            <target type='virtio'/>
          </channel>
      
      we would generate "/var/lib/libvirt/qemu/channel/target/NAME.(null)"
      path which works but is not really correct. Let's not use the
      ".target_name" suffix at all if target name is not set.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1226854Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      ffbafd4e
    • P
      qemu: agent: Don't automatically disable CPU0 via guest agent · 18c9d157
      Peter Krempa 提交于
      While CPU0 was made unpluggable in Linux a while ago it's not desirable
      to unplug it since some parts of the kernel (suspend-to-ram) still
      depend on it.
      
      This patch fixes the vCPU selection code in libvirt so that it will not
      be disabled.
      18c9d157
    • L
      91c9e4d9
    • J
      qemu: properly free addresses on non-serial chardev unplug · 224456fc
      Ján Tomko 提交于
      The target type comparison in qemuDomainDetachChrDevice
      used the VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE enum, so virtio-serial
      addresses were not freed properly for channel devices.
      
      Call qemuDomainReleaseDeviceAddress uncoditionally and decide
      based on the address type instead of the target/device types.
      224456fc
    • L
      qemu: fix address allocation on chardev attach · f967e7a6
      Luyao Huang 提交于
      Also check the device type when deciding what type the address should
      be. Commit 9807c471 (aiming to fix another error in address allocation)
      only checked the target type, but its value is different for different
      device types. This resulted in an error when trying to attach
      a channel with target type 'virtio':
      
      error: Failed to attach device from channel-file.xml
      error: internal error: virtio serial device has invalid address type
      
      Make the logic for releasing the address dependent only on
      * the address type
      * whether it was allocated earlier
      to avoid copying the device and target type checks.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1230039Signed-off-by: NLuyao Huang <lhuang@redhat.com>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      f967e7a6
    • J
      libxl: Set def->vcpus after successfully modifying live vcpu count · 04597f8f
      Jim Fehlig 提交于
      def->vcpus was never updated after successfully changing the live
      vcpu count of a domain. Subsequent queries for vcpu info would
      return incorrect results.  E.g.:
      
      virsh vcpucount test
      maximum      config         4
      maximum      live           4
      current      config         4
      current      live           4
      
      virsh setvcpus test 2
      
      virsh vcpucount test
      maximum      config         4
      maximum      live           4
      current      config         4
      current      live           4
      
      After patch, live current config is reported correctly:
      
      virsh vcpucount test
      maximum      config         4
      maximum      live           4
      current      config         4
      current      live           2
      
      While fixing this, noticed that the live config was not saved
      to cfg->stateDir via virDomainSaveStatus. Save the live config
      and change error handling of virDomainSave{Config,Status} to
      log a message via VIR_WARN, instead of failing the entire
      DomainSetVcpusFlags operation.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      04597f8f
    • J
      libxl: honor domainGetXMLDesc() --inactive flag · 33be48d7
      Jim Fehlig 提交于
      The libxl driver always uses virDomainObj->def when formatting
      the domain XML description.  Use virDomainObj->newDef when
      --inactive flag is set.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      33be48d7
    • J
      libxl: don't remove persistent domain on start failure · 4b53d0d4
      Jim Fehlig 提交于
      libxlDomainCreateXML() would remove a persistent domain if
      libxlDomainStart() failed.  Check if domain is persistent
      before removing.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      4b53d0d4
    • J
      libxl: don't overwrite domain state from statedir config · 29b154e2
      Jim Fehlig 提交于
      When restarting libvirtd and reconnecting to running domains,
      libxlReconnectDomain() would unconditionally set the domain state
      to VIR_DOMAIN_RUNNING, overwriting the state maintained in
      $statedir/<domname>.xml.  A domain in a paused state would have
      the state changed to running, even though it was actually in a
      paused state.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      29b154e2
  3. 30 6月, 2015 14 次提交
  4. 29 6月, 2015 1 次提交
  5. 28 6月, 2015 3 次提交
  6. 27 6月, 2015 6 次提交
    • J
      qemu: Resolve Coverity RESOURCE_LEAK · 782355a7
      John Ferlan 提交于
      Commit id '15fa84ac' added the alias fetch, but forgot to free it.
      782355a7
    • J
      docs: Clarification for when allowed to use 'lun' for "volume" · 91b96438
      John Ferlan 提交于
      While re-reading what I wrote for commit id '785a8940', I realized
      I needed to clarify that being able to present as a 'lun', the mode
      property for the pool source element needed to be "host" (or empty)
      and not "direct".
      
      It was described correctly later in the mode host description, but
      this just ensures it's not missed here as well.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      91b96438
    • L
      docs: document when pcie-root/dmi-to-pci-bridge support was added · 10e207bb
      Laine Stump 提交于
      Also move the mention of version numbers for the various PCI
      controller models up to the end of the sentence where they are first
      given, to avoid confusion.
      10e207bb
    • L
      qemu: ignore assumptions about hotplug requirement when address is from config · 9a12b6cd
      Laine Stump 提交于
      Certain PCI buses don't support hotplug, and when automatically
      assigning PCI addresses for devices, libvirt is very conservative in
      its assumptions about whether or not a device will need to be
      hotplugged/unplugged in the future. But if the user manually assigns
      an address, they likely are aware of any hotplug requirements of the
      device (or at least they should be).
      
      In short, after this patch, automatically PCI address assignment will
      assume that the device must be plugged in to a hot-pluggable slot, but
      manually assignment can place the device in any bus that is
      compatible, regardless of whether or not it supports hotplug. If the
      user makes a mistake and plugs the device into a bus that doesn't
      support hotplug, then later tries to do a hot-unplug, qemu will give
      an appropriate error.
      
      (in the future we may want to add a "hotpluggable" attribute to all
      devices, with default being "yes" for autoassign, and "no" for manual
      assign).
      9a12b6cd
    • L
      qemu: always permit PCI devices to be manually assigned to a PCIe bus · 1e15be1b
      Laine Stump 提交于
      When support for the pcie-root and dmi-to-pci-bridge buses on a Q35
      machinetype was added, I was concerned that even though qemu at the
      time allowed plugging a PCI device into a PCIe port, that it might not
      be supported in the future. To prevent painful backtracking in the
      possible future where this happened, I disallowed such connections
      except in a few specific cases requested by qemu developers (indicated
      in the code with the flag VIR_PCI_CONNECT_TYPE_EITHER_IF_CONFIG).
      
      Now that a couple years have passed, there is a clear message from
      qemu that there is no danger in allowing PCI devices to be plugged
      into PCIe ports. This patch eliminates
      VIR_PCI_CONNECT_TYPE_EITHER_IF_CONFIG and changes the code to always
      allow PCI->PCIe or PCIe->PCI connection *when the PCI address is
      specified in the config. (For newly added devices that haven't yet
      been given a PCI address, the auto-placement still prefers using the
      correct type of bus).
      1e15be1b
    • L
      qemu: refactor qemuBuildControllerDevStr to eliminate future duplicate code · 1074fc50
      Laine Stump 提交于
      The PCI case of the switch statement in this function contains another
      switch statement with a case for each model. Currently every model
      except pci-root and pcie-root has a check for index > 0 (since only
      those two can have index==0), and the function should never be called
      for those two anyway. If we move the check for !pci[e]-root to the top
      of the pci case, then we can move the check for index > 0 out of the
      individual model cases. This will save repeating that check for the
      three new controller models about to be added.
      1074fc50
  7. 26 6月, 2015 1 次提交