Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 02 5月, 2014 1 次提交
  3. 01 5月, 2014 4 次提交
  5. 30 4月, 2014 6 次提交
  7. 29 4月, 2014 17 次提交
  9. 28 4月, 2014 5 次提交
  11. 27 4月, 2014 6 次提交
    • L
      network: centralize check for active network during interface attach · 34cc3b2f
      由 Laine Stump 提交于 
      The check for a network being active during interface attach was being
done individually in several places (by both the lxc driver and the
qemu driver), but those places were too specific, leading to it *not*
being checked when allocating a connection/device from a macvtap or
hostdev network.

This patch puts a single check in networkAllocateActualDevice(), which
is always called before the any network interface is attached to any
type of domain. It also removes all the other now-redundant checks
from the lxc and qemu drivers.

NB: the following patches are prerequisites for this patch, in the
case that it is backported to any branch:

  440beeb7 network: fix virNetworkObjAssignDef and persistence
  8aaa5b68 network: create statedir during driver initialization
  b9e95491 network: change location of network state xml files
  411c5486 network: set macvtap/hostdev networks active if their state
          file exists

This fixes:

  https://bugzilla.redhat.com/show_bug.cgi?id=880483
      34cc3b2f
    • L
      network: set macvtap/hostdev networks active if their state file exists · 411c5486
      由 Laine Stump 提交于 
      libvirt attempts to determine at startup time which networks are
already active, and set their active flags. Previously it has done
this by assuming that all networks are inactive, then setting the
active flag if the network has a bridge device associated with it and
that bridge device exists. This is not useful for macvtap and hostdev
based networks, since they do not use a bridge device.

Of course the reason that such a check had to be done was that the
presence of a status file in the network "stateDir" couldn't be
trusted as an indicator of whether or not a network was active. This
was due to the network driver mistakenly using
/var/lib/libvirt/network to store the status files, rather than
/var/run/libvirt/network (similar to what is done by every other
libvirt driver that stores status xml for its objects). The difference
is that /var/run is cleared out when the host reboots, so you can be
assured that the state file you are seeing isn't just left over from a
previous boot of the host.

Now that the network driver has been switched to using
/var/run/libvirt/network for status, we can also modify it to assume
that any network with an existing status file is by definition active
- we do this when reading the status file. To fine tune the results,
networkFindActiveConfigs() is changed to networkUpdateAllState(),
and only sets active = 0 if the conditions for particular network
types are *not* met.

The result is that during the first run of libvirtd after the host
boots, there are no status files, so no networks are active. Any time
libvirtd is restarted, any network with a status file will be marked
as active (unless the network uses a bridge device and that device for
some reason doesn't exist).
      411c5486
    • L
      network: change location of network state xml files · b9e95491
      由 Laine Stump 提交于 
      For some reason these have been stored in /var/lib, although other
drivers (e.g. qemu and lxc) store their state files in /var/run.

It's much nicer to store state files in /var/run because it is
automatically cleared out when the system reboots. We can then use
existence of the state file as a convenient indicator of whether or
not a particular network is active.

Since changing the location of the state files by itself will cause
problems in the case of a *live* upgrade from an older libvirt that
uses /var/lib (because current status of active networks will be
lost), the network driver initialization has been modified to migrate
any network state files from /var/lib to /var/run.

This will not help those trying to *downgrade*, but in practice this
will only be problematic in two cases

1) If there are networks with network-wide bandwidth limits configured
   *and in use* by a guest during a downgrade to "old" libvirt. In this
   case, the class ID's used for that network's tc rules, as well as
   the currently in-use bandwidth "floor" will be forgotten.

2) If someone does this: 1) upgrade libvirt, 2) downgrade libvirt, 3)
   modify running state of network (e.g. add a static dhcp host, etc),
   4) upgrade. In this case, the modifications to the running network
   will be lost (but not any persistent changes to the network's
   config).
      b9e95491
    • L
      network: create statedir during driver initialization · 8aaa5b68
      由 Laine Stump 提交于 
      This directory should be created when the network driver is first
started up, not just when a dhcp daemon is run. This hasn't posed a
problem in the past, because the directory has always been
pre-existing.
      8aaa5b68
    • L
      network: fix virNetworkObjAssignDef and persistence · 440beeb7
      由 Laine Stump 提交于 
      Experimentation showed that if virNetworkCreateXML() was called for a
network that was already defined, and then the network was
subsequently shutdown, the network would continue to be persistent
after the shutdown (expected/desired), but the original config would
be lost in favor of the transient config sent in with
virNetworkCreateXML() (which would then be the new persistent config)
(obviously unexpected/not desired).

To fix this, virNetworkObjAssignDef() has been changed to

1) properly save/free network->def and network->newDef for all the
various combinations of live/active/persistent, including some
combinations that were previously considered to be an error but didn't
need to be (e.g. setting a "live" config for a network that isn't yet
active but soon will be - that was previously considered an error,
even though in practice it can be very useful).

2) automatically set the persistent flag whenever a new non-live
config is assigned to the network (and clear it when the non-live
config is set to NULL). the libvirt network driver no longer directly
manipulates network->persistent, but instead relies entirely on
virNetworkObjAssignDef() to do the right thing automatically.

After this patch, the following sequence will behave as expected:

virNetworkDefineXML(X)
virNetworkCreateXML(X') (same name but some config different)
virNetworkDestroy(X)

At the end of these calls, the network config will remain as it was
after the initial virNetworkDefine(), whereas previously it would take
on the changes given during virNetworkCreateXML().

Another effect of this tighter coupling between a) setting a !live def
and b) setting/clearing the "persistent" flag, is that future patches
which change the details of network lifecycle management
(e.g. upcoming patches to fix detection of "active" networks when
libvirtd is restarted) will find it much more difficult to break
persistence functionality.
      440beeb7
    • D
      build: -avoid-version on libvirt_driver_nwfilter · 014f317b
      由 Dwight Engen 提交于 
      This fixes the following make rpm warning:

warning: Installed (but unpackaged) file(s) found:
   /usr/lib64/libvirt/connection-driver/libvirt_driver_nwfilter.so.0
   /usr/lib64/libvirt/connection-driver/libvirt_driver_nwfilter.so.0.0.0

introduced in comit 8d559864Signed-off-by: NDwight Engen <dwight.engen@oracle.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
      014f317b
  13. 26 4月, 2014 1 次提交
    • I
      libxl: Support PV consoles · 657cb1e4
      由 Ian Campbell 提交于 
      Currently the driver only exposes the ability to connect to the serial console
of a Xen guest, which doesn't work for a PV guest. Since for an HVM guest the
serial devices are duplicated as consoles it is sufficient to just use the
console devices unconditionally.

Tested with the following bit of config XML:

<domain type='xen'>
  ...
  <devices>
    <console type='pty'>
      <target type='xen'/>
    </console>
  </devices>
</domain>

I have observed and tested this on ARM but I believe it also applies to x86 PV
guests.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Jim Fehlig <jfehlig@suse.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Clark Laughlin <clark.laughlin@linaro.org>
      657cb1e4