1. 09 12月, 2015 4 次提交
  2. 30 11月, 2015 3 次提交
  3. 27 11月, 2015 3 次提交
  4. 25 11月, 2015 2 次提交
    • D
      Allow multiple panic devices · 59fc0d06
      Dmitry Andreev 提交于
      'model' attribute was added to a panic device but only one panic
      device is allowed. This patch changes panic device presence
      from 'optional' to 'zeroOrMore'.
      59fc0d06
    • D
      conf: add 'model' attribute for panic device with values isa, pseries, hyperv · 658ec27f
      Dmitry Andreev 提交于
      Libvirt already has two types of panic devices - pvpanic and pSeries firmware.
      This patch introduces the 'model' attribute and a new type of panic device.
      
      'isa' model is for ISA pvpanic device.
      'pseries' model is a default value for pSeries guests.
      'hyperv' model is the new type. It's used for Hyper-V crash.
      
      Schema and docs are updated for the new attribute.
      658ec27f
  5. 18 11月, 2015 1 次提交
  6. 10 11月, 2015 1 次提交
  7. 05 10月, 2015 1 次提交
  8. 26 9月, 2015 2 次提交
    • S
      qemu: Make virtType of type virDomainVirtType · 7383b8cc
      Shivangi Dhir 提交于
      Earlier virtType was of type int. After, introducing the enum VIR_DOMAIN_VIRT_NONE,
      the type of virtType is modified to virDomainVirtType.
      7383b8cc
    • S
      conf: Add new VIR_DOMAIN_VIRT_NONE enum · 62569e45
      Shivangi Dhir 提交于
      Introduce VIR_DOMAIN_VIRT_NONE to give domaintype the default value of zero.
      This is specially helpful in constructing better error messages
      when we don't want to look up the default emulator by virtType.
      
      The test data in vircapstest.c is also modified to reflect this change.
      62569e45
  9. 22 9月, 2015 7 次提交
    • P
      conf: Don't always recalculate initial memory size from NUMA size totals · 0fed5a7b
      Peter Krempa 提交于
      When implementing memory hotplug I've opted to recalculate the initial
      memory size (contents of the <memory> element) as a sum of the sizes of
      NUMA nodes when NUMA was enabled. This was based on an assumption that
      qemu did not allow starting when the NUMA node size total didn't equal
      to the initial memory size. Unfortunately the check was introduced to
      qemu just lately.
      
      This patch uses the new XML parser flag to decide whether it's safe to
      update the memory size total from the NUMA cell sizes or not.
      
      As an additional improvement we now report an error in case when the
      size of hotplug memory would exceed the total memory size.
      
      The rest of the changes assures that the function is called with correct
      flags.
      0fed5a7b
    • P
      conf: Pre-calculate initial memory size instead of always calculating it · 403e8606
      Peter Krempa 提交于
      Add 'initial_memory' member to struct virDomainMemtune so that the
      memory size can be pre-calculated once instead of inferring it always
      again and again.
      
      Separating of the fields will also allow finer granularity of decisions
      in later patches where it will allow to keep the old initial memory
      value in cases where we are handling incomming migration from older
      versions that did not always update the size from NUMA as the code did
      previously.
      
      The change also requires modification of the qemu memory alignment
      function since at the point where we are modifying the size of NUMA
      nodes the total size needs to be recalculated too.
      
      The refactoring done in this patch also fixes a crash in the hyperv
      driver that did not properly initialize def->numa and thus
      virDomainNumaGetMemorySize(def->numa) crashed.
      
      In summary this patch should have no functional impact at this point.
      403e8606
    • P
      conf: Rename max_balloon to total_memory · 8059a990
      Peter Krempa 提交于
      The name of the variable was misleading. Rename it and it's setting
      accessor before other fixes.
      8059a990
    • P
      conf: Add XML parser flag that will allow us to do incompatible updates · 59173c3d
      Peter Krempa 提交于
      Add a new parser flag that will mark code paths that parse XML files
      wich will not be used with existing VM state so that post parse
      callbacks can possibly do ABI incompatible changes if needed.
      59173c3d
    • P
      conf: Document all VIR_DOMAIN_DEF_PARSE_* flags · 24e3b0ed
      Peter Krempa 提交于
      24e3b0ed
    • P
      conf: Drop VIR_DOMAIN_DEF_PARSE_CLOCK_ADJUST flag · ed94ad9e
      Peter Krempa 提交于
      The flag was used only for formatting the XML and once the parser and
      formatter flags were split in 0ecd6851
      it doesn't make sense any more to have it.
      ed94ad9e
    • P
      conf: Add helper to determine whether memory hotplug is enabled for a vm · 1891cad5
      Peter Krempa 提交于
      Add a simple helper so that the code doesn't have to rewrite the same
      condition multiple times.
      1891cad5
  10. 18 9月, 2015 1 次提交
  11. 02 9月, 2015 1 次提交
    • J
      qemu: add udp interface support · 5c668a78
      Jonathan Toppins 提交于
      Adds a new interface type using UDP sockets, this seems only applicable
      to QEMU but have edited tree-wide to support the new interface type.
      
      The interface type required the addition of a "localaddr" (local
      address), this then maps into the following xml and qemu call.
      
      <interface type='udp'>
        <mac address='52:54:00:5c:67:56'/>
        <source address='127.0.0.1' port='11112'>
          <local address='127.0.0.1' port='22222'/>
        </source>
        <model type='virtio'/>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
      </interface>
      
      QEMU call:
      	-net socket,udp=127.0.0.1:11112,localaddr=127.0.0.1:22222
      
      Notice the xml "local" entry becomes the "localaddr" for the qemu call.
      
      reference:
      http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.htmlSigned-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com>
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      5c668a78
  12. 14 8月, 2015 1 次提交
  13. 13 8月, 2015 2 次提交
  14. 10 8月, 2015 6 次提交
    • M
      conf: Add ioeventfd option for controllers · 35eecdde
      Martin Kletzander 提交于
      This will be used with a virtio-scsi controller later on.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      35eecdde
    • L
      conf: new pcie-controller model "pcie-switch-downstream-port" · 76379a6e
      Laine Stump 提交于
      This controller can be connected only to a port on a
      pcie-switch-upstream-port. It provides a single hotpluggable port that
      will accept any PCI or PCIe device, as well as any device requiring a
      pcie-*-port (the only current example of such a device is the
      pcie-switch-upstream-port).
      76379a6e
    • L
      conf: new pci controller model "pcie-switch-upstream-port" · 38ea9515
      Laine Stump 提交于
      This controller can be connected only to a pcie-root-port or a
      pcie-switch-downstream-port (which will be added in a later patch),
      which is the reason for the new connect type
      VIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides
      32 ports (slot=0 to slot=31) on the downstream side, which can only
      have pci controllers of model "pcie-switch-downstream-port" plugged
      into them, which is the reason for the other new connect type
      VIR_PCI_CONNECT_TYPE_PCIE_SWITCH.
      38ea9515
    • L
      conf: new pci controller model "pcie-root-port" · dce3b8be
      Laine Stump 提交于
      This controller can be connected (at domain startup time only - not
      hotpluggable) only to a port on the pcie root complex ("pcie-root" in
      libvirt config), hence the new connect type
      VIR_PCI_CONNECT_TYPE_PCIE_ROOT. It provides a hotpluggable port that
      will accept any PCI or PCIe device.
      
      New attributes must be added to the controller <target> subelement for
      this - chassis and port are guest-visible option values that will be
      set by libvirt with values derived from the controller's index and pci
      address information.
      dce3b8be
    • L
      conf: add new <target> subelement with chassisNr attribute to <controller> · 8dc88aee
      Laine Stump 提交于
      There are some configuration options to some types of pci controllers
      that are currently automatically derived from other parts of the
      controller's configuration. For example, in qemu a pci-bridge
      controller has an option that is called "chassis_nr"; up until now
      libvirt has always set chassis_nr to the index of the pci-bridge. So
      this:
      
        <controller type='pci' model='pci-bridge' index='2'/>
      
      will always result in:
      
        -device pci-bridge,chassis_nr=2,...
      
      on the qemu commandline. In the future we may decide there is a better
      way to derive that option, but even in that case we will need for
      existing domains to retain the same chassis_nr they were using in the
      past - that is something that is visible to the guest so it is part of
      the guest ABI and changing it would lead to problems for migrating
      guests (or just guests with very picky OSes).
      
      The <target> subelement has been added as a place to put the new
      "chassisNr" attribute that will be filled in by libvirt when it
      auto-generates the chassisNr; it will be saved in the config, then
      reused any time the domain is started:
      
        <controller type='pci' model='pci-bridge' index='2'>
          <model type='pci-bridge'/>
          <target chassisNr='2'/>
        </controller>
      
      The one oddity of all this is that if the controller configuration
      is changed (for example to change the index or the pci address
      where the controller is plugged in), the items in <target> will
      *not* be re-generated, which might lead to conflict. I can't
      really see any way around this, but fortunately if there is a
      material conflict qemu will let us know and we will pass that on
      to the user.
      8dc88aee
    • L
      conf: add new <model> subelement with name attribute to <controller> · bf202510
      Laine Stump 提交于
      This new subelement is used in PCI controllers: the toplevel
      *attribute* "model" of a controller denotes what kind of PCI
      controller is being described, e.g. a "dmi-to-pci-bridge",
      "pci-bridge", or "pci-root". But in the future there will be different
      implementations of some of those types of PCI controllers, which
      behave similarly from libvirt's point of view (and so should have the
      same model), but use a different device in qemu (and present
      themselves as a different piece of hardware in the guest). In an ideal
      world we (i.e. "I") would have thought of that back when the pci
      controllers were added, and used some sort of type/class/model
      notation (where class was used in the way we are now using model, and
      model was used for the actual manufacturer's model number of a
      particular family of PCI controller), but that opportunity is long
      past, so as an alternative, this patch allows selecting a particular
      implementation of a pci controller with the "name" attribute of the
      <model> subelement, e.g.:
      
        <controller type='pci' model='dmi-to-pci-bridge' index='1'>
          <model name='i82801b11-bridge'/>
        </controller>
      
      In this case, "dmi-to-pci-bridge" is the kind of controller (one that
      has a single PCIe port upstream, and 32 standard PCI ports downstream,
      which are not hotpluggable), and the qemu device to be used to
      implement this kind of controller is named "i82801b11-bridge".
      
      Implementing the above now will allow us in the future to add a new
      kind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge
      device, but instead uses something else (which doesn't yet exist, but
      qemu people have been discussing it), all without breaking existing
      configs.
      
      (note that for the existing "pci-bridge" type of PCI controller, both
      the model attribute and <model> name are 'pci-bridge'. This is just a
      coincidence, since it turns out that in this case the device name in
      qemu really is a generic 'pci-bridge' rather than being the name of
      some real-world chip)
      bf202510
  15. 04 8月, 2015 1 次提交
    • J
      conf: Allow error reporting in virDomainDiskSourceIsBlockType · 36025c55
      John Ferlan 提交于
      Rather than provide a somewhat generic error message when the API
      returns false, allow the caller to supply a "report = true" option
      in order to cause virReportError's to describe which of the 3 paths
      that can cause failure.
      
      Some callers don't care about what caused the failure, they just want
      to have a true/false - for those, calling with report = false should
      be sufficient.
      36025c55
  16. 20 7月, 2015 1 次提交
    • M
      qemu: Reject updating unsupported disk information · 717c99f3
      Martin Kletzander 提交于
      If one calls update-device with information that is not updatable,
      libvirt reports success even though no data were updated.  The example
      used in the bug linked below uses updating device with <boot order='2'/>
      which, in my opinion, is a valid thing to request from user's
      perspective.  Mainly since we properly error out if user wants to update
      such data on a network device for example.
      
      And since there are many things that might happen (update-device on disk
      basically knows just how to change removable media), check for what's
      changing and moreover, since the function might be usable in other
      drivers (updating only disk path is a valid possibility) let's abstract
      it for any two disks.
      
      We can't possibly check for everything since for many fields our code
      does not properly differentiate between default and unspecified values.
      Even though this could be changed, I don't feel like it's worth the
      complexity so it's not the aim of this patch.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1007228
      717c99f3
  17. 10 7月, 2015 1 次提交
  18. 08 7月, 2015 1 次提交
  19. 01 7月, 2015 1 次提交
    • P
      conf: qemu: Taint VMs using custom device tree blob · 4b48ba4a
      Peter Krempa 提交于
      Using a custom device tree image may cause unexpected behavior in
      architectures that use this approach to detect platform devices. Since
      usually the device tree is generated by qemu and thus it's not normally
      used let's taint VMs using it to make it obvious as a possible source of
      problems.
      4b48ba4a