1. 22 11月, 2019 1 次提交
  2. 21 11月, 2019 1 次提交
    • J
      qemu: Store default CPU in domain XML · 5e939cea
      Jiri Denemark 提交于
      When starting a domain without a CPU model specified in the domain XML,
      QEMU will choose a default one. Which is fine unless the domain gets
      migrated to another host because libvirt doesn't perform any CPU ABI
      checks and the virtual CPU provided by QEMU on the destination host can
      differ from the one on the source host.
      
      With QEMU 4.2.0 we can probe for the default CPU model used by QEMU for
      a particular machine type and store it in the domain XML. This way the
      chosen CPU model is more visible to users and libvirt will make sure
      the guest will see the exact same CPU after migration.
      
      Architecture specific notes
      - aarch64: We only set the default CPU for TCG domains as KVM requires
        explicit "-cpu host" to work.
      
      - ppc64: The default CPU for KVM is "host" thanks to some hacks in QEMU,
        we will translate the default model to the model corresponding to the
        host CPU ("POWER8" on a Power8 host, "POWER9" on Power9 host, etc.).
        This is not a problem as the corresponding CPU model is in fact an
        alias for "host". This is probably not ideal, but it's not wrong and
        the default virtual CPU configured by libvirt is the same QEMU would
        use. TCG uses various CPU models depending on machine type and its
        version.
      
      - s390x: The default CPU for KVM is "host" while TCG defaults to "qemu".
      
      - x86_64: The default CPU model (qemu64) is not runnable on any host
        with KVM, but QEMU just disables unavailable features and starts
        happily.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1598151
      https://bugzilla.redhat.com/show_bug.cgi?id=1598162Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      5e939cea
  3. 12 4月, 2019 1 次提交
  4. 15 3月, 2019 2 次提交
  5. 08 2月, 2019 1 次提交
  6. 23 7月, 2018 3 次提交
  7. 06 6月, 2018 1 次提交
    • D
      qemu: support passing pre-opened UNIX socket listen FD · 30fb2276
      Daniel P. Berrangé 提交于
      There is a race condition when spawning QEMU where libvirt has spawned
      QEMU but the monitor socket is not yet open. Libvirt has to repeatedly
      try to connect() to QEMU's monitor until eventually it succeeds, or
      times out. We use kill() to check if QEMU is still alive so we avoid
      waiting a long time if QEMU exited, but having a timeout at all is still
      unpleasant.
      
      With QEMU 2.12 we can pass in a pre-opened FD for UNIX domain or TCP
      sockets. If libvirt has called bind() and listen() on this FD, then we
      have a guarantee that libvirt can immediately call connect() and
      succeed without any race.
      
      Although we only really care about this for the monitor socket and agent
      socket, this patch does FD passing for all UNIX socket based character
      devices since there appears to be no downside to it.
      
      We don't do FD passing for TCP sockets, however, because it is only
      possible to pass a single FD, while some hostnames may require listening
      on multiple FDs to cover IPv4 and IPv6 concurrently.
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      30fb2276
  8. 19 4月, 2018 2 次提交