Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 26 2月, 2015 2 次提交
    • L
      qemu: fix ifindex array reported to systemd · 4bbe1029
      由 Laine Stump 提交于 
      Commit f7afeddc added code to report to systemd an array of interface
indexes for all tap devices used by a guest. Unfortunately it not only
didn't add code to report the ifindexes for macvtap interfaces
(interface type='direct') or the tap devices used by type='ethernet',
it ended up sending "-1" as the ifindex for each macvtap or hostdev
interface. This resulted in a failure to start any domain that had a
macvtap or hostdev interface (or actually any type other than
"network" or "bridge").

This patch does the following with the nicindexes array:

1) Modify qemuBuildInterfaceCommandLine() to only fill in the
nicindexes array if given a non-NULL pointer to an array (and modifies
the test jig calls to the function to send NULL). This is because
there are tests in the test suite that have type='ethernet' and still
have an ifname specified, but that device of course doesn't actually
exist on the test system, so attempts to call virNetDevGetIndex() will
fail.

2) Even then, only add an entry to the nicindexes array for
appropriate types, and to do so for all appropriate types ("network",
"bridge", and "direct"), but only if the ifname is known (since that
is required to call virNetDevGetIndex().
      4bbe1029
    • L
      network: only clear bandwidth if it has been set · 118b2408
      由 Laine Stump 提交于 
      libvirt was unconditionally calling virNetDevBandwidthClear() for
every interface (and network bridge) of a type that supported
bandwidth, whether it actually had anything set or not. This doesn't
hurt anything (unless ifname == NULL!), but is wasteful.

This patch makes sure that all calls to virNetDevBandwidthClear() are
qualified by checking that the interface really had some bandwidth
setup done, and checks for a null ifname inside
virNetDevBandwidthClear(), silently returning success if it is null
(as well as removing the ATTRIBUTE_NONNULL from that function's
prototype, since we can't guarantee that it is never null,
e.g. sometimes a type='ethernet' interface has no ifname as it is
provided on the fly by qemu).
      118b2408
  3. 13 2月, 2015 1 次提交
  5. 10 2月, 2015 2 次提交
  7. 28 1月, 2015 2 次提交
    • J
      hotplug: only add a chardev to vmdef after monitor call · 21e0e886
      由 Ján Tomko 提交于 
      https://bugzilla.redhat.com/show_bug.cgi?id=1161024

This way the device is in vmdef only if ret = 0 and the caller
(qemuDomainAttachDeviceFlags) does not free it.

Otherwise it might get double freed by qemuProcessStop
and qemuDomainAttachDeviceFlags if the domain crashed
in monitor after we've added it to vm->def.
      21e0e886
    • J
      Split qemuDomainChrInsert into two parts · daf51be5
      由 Ján Tomko 提交于 
      Do the allocation first, then add the actual device.
The second part should never fail. This is good
for live hotplug where we don't want to remove the device
on OOM after the monitor command succeeded.

The only change in behavior is that on failure, the
vmdef->consoles array is freed, not just the first console.
      daf51be5
  9. 27 1月, 2015 2 次提交
  11. 19 1月, 2015 3 次提交
  13. 15 1月, 2015 1 次提交
  15. 14 1月, 2015 1 次提交
  17. 07 1月, 2015 1 次提交
  19. 06 1月, 2015 2 次提交
  21. 18 12月, 2014 2 次提交
  23. 17 12月, 2014 1 次提交
  25. 15 12月, 2014 3 次提交
  27. 14 12月, 2014 1 次提交
    • L
      qemu: add a qemuInterfaceStopDevices(), called when guest CPUs stop · c5a54917
      由 Laine Stump 提交于 
      We now have a qemuInterfaceStartDevices() which does the final
activation needed for the host-side tap/macvtap devices that are used
for qemu network connections. It will soon make sense to have the
converse qemuInterfaceStopDevices() which will undo whatever was done
during qemuInterfaceStartDevices().

A function to "stop" a single device has also been added, and is
called from the appropriate place in qemuDomainDetachNetDevice(),
although this is currently unnecessary - the device is going to
immediately be deleted anyway, so any extra "deactivation" will be for
naught. The call is included for completeness, though, in anticipation
that in the future there may be some required action that *isn't*
nullified by deleting the device.

This patch is a part of a more complete fix for:

  https://bugzilla.redhat.com/show_bug.cgi?id=1081461
      c5a54917
  29. 11 12月, 2014 1 次提交
    • M
      network: Bring netdevs online later · 82977058
      由 Matthew Rosato 提交于 
      Currently, MAC registration occurs during device creation, which is
early enough that, during live migration, you end up with duplicate
MAC addresses on still-running source and target devices, even though
the target device isn't actually being used yet.
This patch proposes to defer MAC registration until right before
the guest can actually use the device -- In other words, right
before starting guest CPUs.
Signed-off-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: NLaine Stump <laine@laine.org>
      82977058
  31. 10 12月, 2014 1 次提交
  33. 09 12月, 2014 1 次提交
    • 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
  35. 03 12月, 2014 1 次提交
    • J
      Replace virNetworkFree with virObjectUnref · 121c09a9
      由 John Ferlan 提交于 
      Since virNetworkFree will call virObjectUnref anyway, let's just use that
directly so as to avoid the possibility that we inadvertently clear out
a pending error message when using the public API.
      121c09a9
  37. 02 12月, 2014 1 次提交
    • J
      hotplug: Resolve Coverity FORWARD_NULL · 59802f23
      由 John Ferlan 提交于 
      Coverity complained that because the cfg->macFilter call checked
net->ifname != NULL before calling ebtablesRemoveForwardAllowIn, then
the virNetDevOpenvswitchRemovePort call should have the same check.

However, if I move the ebtables call prior to the check for TYPE_DIRECT
(where there is a VIR_FREE(net->ifname)), then it seems Coverity is
happy.  Since firewall info is tacked on last during setup, removing
it in the opposite order of initialization seems to be natural anyway
      59802f23
  39. 01 12月, 2014 2 次提交
  41. 19 11月, 2014 1 次提交
  43. 15 11月, 2014 1 次提交
  45. 01 11月, 2014 1 次提交
    • P
      hotplug: fix char device detach · e7e05801
      由 Pavel Hrdina 提交于 
      Hotplugging and hotunplugging char devices is only supported through
'-device' and the check for device capability should be independently.

Coverity also complains about 'tmpChr->info.alias' could be NULL and we
are dereferencing it but it somehow only in this case don't recognize
that the value is set by 'qemuAssignDeviceChrAlias' so it's clearly
false positive. Add sa_assert to make coverity happy.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      e7e05801
  47. 30 10月, 2014 1 次提交
  49. 29 10月, 2014 5 次提交