1. 27 4月, 2014 5 次提交
    • 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
  2. 26 4月, 2014 2 次提交
    • 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
    • D
      build: add nwfilterxml2firewalldata to dist · 2a1ea906
      Dwight Engen 提交于
      Signed-off-by: NDwight Engen <dwight.engen@oracle.com>
      2a1ea906
  3. 25 4月, 2014 33 次提交