1. 21 2月, 2015 4 次提交
    • P
      conf: numa: Always allocate the NUMA config · 21008c01
      Peter Krempa 提交于
      Since our formatter now handles well if the config is allocated and not
      filled we can safely always-allocate the NUMA config and remove the
      ad-hoc allocation code.
      
      This will help in later patches as the parser will be refactored to just
      fill the data.
      21008c01
    • P
      conf: Separate helper for creating domain objects · 61e43ce9
      Peter Krempa 提交于
      Move the existing virDomainDefNew to virDomainDefNewFull as it's setting
      a few things in the conf and re-introduce virDomainDefNew as a function
      without parameters for common use.
      61e43ce9
    • P
      conf: numa: Rename virDomainNumatune to virDomainNuma · 6bc80fa8
      Peter Krempa 提交于
      The structure will gradually become the only place for NUMA related
      config, thus rename it appropriately.
      6bc80fa8
    • P
      conf: Move numatune_conf to numa_conf · fcee64e7
      Peter Krempa 提交于
      For a while now there are two places that gather information about NUMA
      related guest configuration. While the XML can't be changed we can at
      least store the data in one place in the definition.
      
      Rename the numatune_conf.[ch] files to numa_conf as later patches will
      move the rest of the definitions from the cpu definition to this one.
      fcee64e7
  2. 17 2月, 2015 1 次提交
  3. 13 2月, 2015 2 次提交
  4. 12 2月, 2015 2 次提交
  5. 10 2月, 2015 4 次提交
  6. 03 2月, 2015 1 次提交
  7. 31 1月, 2015 5 次提交
  8. 30 1月, 2015 1 次提交
  9. 28 1月, 2015 1 次提交
    • 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
  10. 27 1月, 2015 2 次提交
    • D
      Removing probing of secondary drivers · 55ea7be7
      Daniel P. Berrange 提交于
      For stateless, client side drivers, it is never correct to
      probe for secondary drivers. It is only ever appropriate to
      use the secondary driver that is associated with the
      hypervisor in question. As a result the ESX & HyperV drivers
      have both been forced to do hacks where they register no-op
      drivers for the ones they don't implement.
      
      For stateful, server side drivers, we always just want to
      use the same built-in shared driver. The exception is
      virtualbox which is really a stateless driver and so wants
      to use its own server side secondary drivers. To deal with
      this virtualbox has to be built as 3 separate loadable
      modules to allow registration to work in the right order.
      
      This can all be simplified by introducing a new struct
      recording the precise set of secondary drivers each
      hypervisor driver wants
      
      struct _virConnectDriver {
          virHypervisorDriverPtr hypervisorDriver;
          virInterfaceDriverPtr interfaceDriver;
          virNetworkDriverPtr networkDriver;
          virNodeDeviceDriverPtr nodeDeviceDriver;
          virNWFilterDriverPtr nwfilterDriver;
          virSecretDriverPtr secretDriver;
          virStorageDriverPtr storageDriver;
      };
      
      Instead of registering the hypervisor driver, we now
      just register a virConnectDriver instead. This allows
      us to remove all probing of secondary drivers. Once we
      have chosen the primary driver, we immediately know the
      correct secondary drivers to use.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      55ea7be7
    • D
      don't disable state driver when libvirtd is not built · 220c01aa
      Daniel P. Berrange 提交于
      A bunch of code is wrapped in #if WITH_LIBVIRTD in order to
      enable the virStateDriver to be disabled when libvirtd is not
      built. Disabling this code doesn't have any real functional
      benefit beyond removing 1 pointer from the virConnectPtr struct,
      while having a cost of many more conditionals.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      220c01aa
  11. 26 1月, 2015 2 次提交
    • D
      systemd: avoid string comparisons on dbus error messages · 2d8b59c0
      Daniel P. Berrange 提交于
      Add a virDBusErrorIsUnknownMethod helper so that callers
      don't need todo string comparisons themselves to detect
      standard error names.
      2d8b59c0
    • D
      systemd: fix build without dbus · d13b586a
      Daniel P. Berrange 提交于
      The virDBusMethodCall method has a DBusError as one of its
      parameters. If the caller wants to pass a non-NULL value
      for this, it immediately makes the calling code require
      DBus at build time. This has led to breakage of non-DBus
      builds several times. It is desirable that only the virdbus.c
      file should need WITH_DBUS conditionals, so we must ideally
      remove the DBusError parameter from the method.
      
      We can't simply raise a libvirt error, since the whole point
      of this parameter is to give the callers a way to check if
      the error is one they want to ignore, without having the logs
      polluted with an error message. So, we add a virErrorPtr
      parameter which the caller can then either ignore or raise
      using the new virReportErrorObject method.
      
      This new method is distinct from virSetError in that it
      ensures the logging hooks are run.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      d13b586a
  12. 16 1月, 2015 1 次提交
  13. 15 1月, 2015 1 次提交
  14. 14 1月, 2015 1 次提交
    • D
      Give virDomainDef parser & formatter their own flags · 0ecd6851
      Daniel P. Berrange 提交于
      The virDomainDefParse* and virDomainDefFormat* methods both
      accept the VIR_DOMAIN_XML_* flags defined in the public API,
      along with a set of other VIR_DOMAIN_XML_INTERNAL_* flags
      defined in domain_conf.c.
      
      This is seriously confusing & error prone for a number of
      reasons:
      
       - VIR_DOMAIN_XML_SECURE, VIR_DOMAIN_XML_MIGRATABLE and
         VIR_DOMAIN_XML_UPDATE_CPU are only relevant for the
         formatting operation
       - Some of the VIR_DOMAIN_XML_INTERNAL_* flags only apply
         to parse or to format, but not both.
      
      This patch cleanly separates out the flags. There are two
      distint VIR_DOMAIN_DEF_PARSE_* and VIR_DOMAIN_DEF_FORMAT_*
      flags that are used by the corresponding methods. The
      VIR_DOMAIN_XML_* flags received via public API calls must
      be converted to the VIR_DOMAIN_DEF_FORMAT_* flags where
      needed.
      
      The various calls to virDomainDefParse which hardcoded the
      use of the VIR_DOMAIN_XML_INACTIVE flag change to use the
      VIR_DOMAIN_DEF_PARSE_INACTIVE flag.
      0ecd6851
  15. 06 1月, 2015 4 次提交
  16. 23 12月, 2014 1 次提交
  17. 16 12月, 2014 3 次提交
  18. 15 12月, 2014 1 次提交
  19. 09 12月, 2014 3 次提交
    • L
      network: store network macTableManager setting in NetDef actual object · 33f4a8bc
      Laine Stump 提交于
      At the time that the network driver allocates a connection to a
      network, the tap device that will be used hasn't yet been created -
      that will be done later by qemu (or lxc or whoever) - but if the
      network has macTableManager='libvirt', then when we do get around to
      creating the tap device, we will need to add an entry for it to the
      network bridge's fdb (forwarding database) *and* turn off learning and
      unicast_flood for that tap device in the bridge's sysfs settings. This
      means that qemu needs to know both the bridge name as well as the
      setting of macTableManager, so we either need to create a new API to
      retrieve that info, or just pass it back in the ActualNetDef that is
      created during networkAllocateActualDevice. We choose the latter
      method, since it's already done for the bridge device, and it has the
      side effect of making the information available in domain status.
      
      (NB: in the future, I think that the tap device should actually be
      created by networkAllocateActualDevice(), as that will solve several
      other problems, but that is a battle for another day, and this
      information will still be useful outside the network driver)
      33f4a8bc
    • L
      conf: new network bridge device attribute macTableManager · 40961978
      Laine Stump 提交于
      The macTableManager attribute of a network's bridge subelement tells
      libvirt how the bridge's MAC address table (used to determine the
      egress port for packets) is managed. In the default mode, "kernel",
      management is left to the kernel, which usually determines entries in
      part by turning on promiscuous mode on all ports of the bridge,
      flooding packets to all ports when the correct destination is unknown,
      and adding/removing entries to the fdb as it sees incoming traffic
      from particular MAC addresses.  In "libvirt" mode, libvirt turns off
      learning and flooding on all the bridge ports connected to guest
      domain interfaces, and adds/removes entries according to the MAC
      addresses in the domain interface configurations. A side effect of
      turning off learning and unicast_flood on the ports of a bridge is
      that (with Linux kernel 3.17 and newer), the kernel can automatically
      turn off promiscuous mode on one or more of the bridge's ports
      (usually only the one interface that is used to connect the bridge to
      the physical network). The result is better performance (because
      packets aren't being flooded to all ports, and can be dropped earlier
      when they are of no interest) and slightly better security (a guest
      can still send out packets with a spoofed source MAC address, but will
      only receive traffic intended for the guest interface's configured MAC
      address).
      
      The attribute looks like this in the configuration:
      
        <network>
          <name>test</name>
          <bridge name='br0' macTableManager='libvirt'/>
          ...
      
      This patch only adds the config knob, documentation, and test
      cases. The functionality behind this knob is added in later patches.
      40961978
    • L
      util: functions to manage bridge fdb (forwarding database) · 19a5474d
      Laine Stump 提交于
      These two functions use netlink RTM_NEWNEIGH and RTM_DELNEIGH messages
      to add and delete entries from a bridge's fdb. The bridge itself is
      not referenced in the arguments to the functions, only the name of the
      device that is attached to the bridge (since a device can only be
      attached to one bridge at a time, and must be attached for this
      function to make sense, the kernel easily infers which bridge's fdb is
      being modified by looking at the device name/index).
      19a5474d