1. 29 7月, 2014 2 次提交
  2. 17 7月, 2014 5 次提交
  3. 14 7月, 2014 1 次提交
  4. 02 7月, 2014 1 次提交
  5. 27 6月, 2014 1 次提交
  6. 07 6月, 2014 1 次提交
    • E
      conf: alter disk mirror xml output · 7c6fc394
      Eric Blake 提交于
      Now that we track a disk mirror as a virStorageSource, we might
      as well update the XML to theoretically allow any type of
      mirroring destination (not just a local file).  A later patch
      will also be reusing <mirror> to track the block commit of the
      top layer of a chain, which is another case where libvirt needs
      to update the backing chain after the job is finally pivoted,
      and since backing chains can have network backing files as the
      destination to commit into, it makes more sense to display that
      in the XML.
      
      This patch changes output-only XML; it was already documented
      that <mirror> does not affect a domain definition at this point
      (because qemu doesn't provide persistent bitmaps yet).  Any
      application that was starting a block copy job with older libvirt
      and then relying on the domain XML to determine if it was
      complete will no longer be able to access the file= and format=
      attributes of mirror that were previously used.  However, this is
      not going to be a problem in practice: the only time a block copy
      job works is on a transient domain, and any app that is managing
      a transient domain probably already does enough of its own
      bookkeeping to know which file it is mirroring into without
      having to re-read it from the libvirt XML.  The one thing that
      was likely to be used in a mirroring job was the ready=
      attribute, which is unchanged.  Meanwhile, I made sure the schema
      and parser still accept the old format, even if we no longer
      output it, so that upgrading from an older version of libvirt is
      seamless.
      
      * docs/schemas/domaincommon.rng (diskMirror): Alter definition.
      * src/conf/domain_conf.c (virDomainDiskDefParseXML): Parse two
      styles of mirror elements.
      (virDomainDiskDefFormat): Output new style.
      * tests/qemuxml2argvdata/qemuxml2argv-disk-mirror-old.xml: New
      file, copied from...
      * tests/qemuxml2argvdata/qemuxml2argv-disk-mirror.xml: ...here
      before modernizing.
      * tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-mirror-old*: New
      files.
      * tests/qemuxml2xmltest.c (mymain): Test both styles.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      7c6fc394
  7. 19 5月, 2014 1 次提交
    • J
      conf: fix seclabels for chardevs · 5ac9b9dd
      Ján Tomko 提交于
      We allow a seclabel to be specified in the <source> element
      of a chardev:
      
      <serial type='file'>
        <source path='/tmp/serial.file'>
          <seclabel model='dac' relabel='no'/>
        </source>
      </serial>
      
      But we format it outside the source:
      
      <serial type='file'>
        <source path='/tmp/serial.file'/>
        <target port='0'/>
          <seclabel model='dac' relabel='no'/>
      </serial>
      
      Move the formatting inside the source to fix this to make the
      seclabel persistent across XML format->parse.
      
      Introduced by commit f8b08d0e 'Add <seclabel> to character devices.'
      5ac9b9dd
  8. 24 4月, 2014 2 次提交
  9. 16 4月, 2014 1 次提交
    • E
      conf: fix omission of <driver> in domain dumpxml · 8fb44675
      Eric Blake 提交于
      I noticed that depending on the <driver> attributes the user passed
      in, the output may omit the <driver> element altogether.  For example,
      the rerror_policy has had this problem since commit 4bb4109f in Oct
      2011.  But in adding testsuite coverage to expose it, I found another
      problem: the C code is just fine without a driver name, but the
      XML validator required either a name or a cache mode.
      
      * src/conf/domain_conf.c (virDomainDiskDefFormat): Update
      conditional.
      * docs/schemas/domaincommon.rng (diskDriver): Simplify.
      * tests/qemuxml2argvdata/qemuxml2argv-disk-drive-copy-on-read.xml:
      * tests/qemuxml2argvdata/qemuxml2argv-disk-drive-copy-on-read.args:
      New files.
      * tests/qemuxml2argvdata/qemuxml2argv-disk-drive-discard.xml:
      Enhance test.
      * tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-discard.xml:
      Likewise.
      * tests/qemuxml2argvtest.c (mymain): New test.
      * tests/qemuxml2xmltest.c (mymain): Likewise.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      8fb44675
  10. 15 4月, 2014 1 次提交
    • E
      conf: better <disk> interleaving in schema · a9efe2d7
      Eric Blake 提交于
      In general, we try to make virt-xml-validate tolerant of input
      elements in any order when possible.  However, as written, the
      RNG grammar did not permit <source> unless there was an explicit
      type= attribute (even though the C code manages just fine by
      defaulting to type='file').  After making the attribute optional
      on the 'file' branch, I noticed that the use of diskspec was now
      redundant with the branch when no <source> was supplied.
      
      View this patch with 'git diff -b' for a better picture of the
      schema change.
      
      * docs/schemas/domaincommon.rng (disk): Hoist 'diskspec' out of
      choice, make type='file' default, and still preserve interleave.
      * tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-source-pool.xml:
      * tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-discard.xml:
      New files.
      * tests/qemuxml2argvdata/qemuxml2argv-disk-source-pool.xml:
      * tests/qemuxml2argvdata/qemuxml2argv-disk-drive-discard.xml:
      Reorder XML.
      * tests/qemuxml2xmltest.c (mymain): Cover new files.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      a9efe2d7
  11. 26 3月, 2014 1 次提交
    • J
      Treat zero cpu shares as a valid value · bdffab0d
      Ján Tomko 提交于
      Currently, <cputune><shares>0</shares></cputune> is treated
      as if it were not specified.
      
      Treat is as a valid value if it was explicitly specified
      and write it to the cgroups.
      bdffab0d
  12. 25 3月, 2014 1 次提交
  13. 18 3月, 2014 1 次提交
  14. 11 2月, 2014 1 次提交
    • M
      qemu: introduce spiceport chardev backend · d27e6bc4
      Martin Kletzander 提交于
      Add a new backend for any character device.  This backend uses channel
      in spice connection.  This channel is similar to spicevmc, but
      all-purpose in contrast to spicevmc.
      
      Apart from spicevmc, spiceport-backed chardev will not be formatted
      into the command-line if there is no spice to use (with test for that
      as well).  For this I moved the def->graphics counting to the start
      of the function so its results can be used in rest of the code even in
      the future.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      d27e6bc4
  15. 10 2月, 2014 2 次提交
    • P
      qemu: hyperv: Add support for timer enlightenments · 600bca59
      Peter Krempa 提交于
      Add a new <timer> for the HyperV reference time counter enlightenment
      and the iTSC reference page for Windows guests.
      
      This feature provides a paravirtual approach to track timer events for
      the guest (similar to kvmclock) with the option to use real hardware
      clock on systems with a iTSC with compensation across various hosts.
      600bca59
    • P
      schema: Fix guest timer specification schema according to the docs · bbd392ff
      Peter Krempa 提交于
      According to the documentation describing various tunables for domain
      timers not all the fields are supported by all the driver types. Express
      these in the RNG:
      
      - rtc, platform: Only these support the "track" attribute.
      - tsc: only one to support "frequency" and "mode" attributes
      - hpet, pit: tickpolicy/catchup attribute/element
      - kvmclock: no extra attributes are supported
      
      Additionally the attributes of the <catchup> element for
      tickpolicy='catchup' are optional according to the parsing code. Express
      this in the XML and fix a spurious space added while formatting the
      <catchup> element and add tests for it.
      bbd392ff
  16. 11 1月, 2014 1 次提交
  17. 13 12月, 2013 1 次提交
  18. 10 12月, 2013 1 次提交
  19. 11 11月, 2013 1 次提交
    • M
      virSecurityLabelDefParseXML: Don't parse label on model='none' · 9fb3f957
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1027096
      
      If there's the following snippet in the domain XML, the domain will be
      lost upon the daemon restart (if the domain is started prior restart):
      
          <seclabel type='dynamic' relabel='yes'/>
      
      The problem is, the 'label', 'imagelabel' and 'baselabel' are parsed
      whenever the VIR_DOMAIN_XML_INACTIVE is *not* present or the label is
      static. The latter is not our case, obviously. So, when libvirtd starts
      up, it finds domain state xml and parse it. During parsing, many XML
      flags are enabled but VIR_DOMAIN_XML_INACTIVE. Hence, our parser tries
      to extract 'label', 'imagelabel' and 'baselabel' from the XML which
      fails for model='none'. Err, this model - even though not specified in
      XML - can be taken from qemu wide config file: /etc/libvirtd/qemu.conf.
      
      However, in order to know we are dealing with model='none' the code in
      question must be moved forward a bit. Then a new check must be
      introduced. This is what the first two chunks are doing.
      
      But this alone is not sufficient. The domain state XML won't contain the
      model attribute without slight modification. The model should be
      inserted into the XML even if equal to 'none' and the state XML is being
      generated - what if the origin (the @security_driver variable in
      qemu.conf) changes during libvirtd restarts?
      
      At the end, a test to catch this scenario is introduced.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      9fb3f957
  20. 08 11月, 2013 1 次提交
  21. 08 10月, 2013 2 次提交
  22. 27 8月, 2013 1 次提交
    • J
      Add pcihole64 element to root PCI controllers · 01cda918
      Ján Tomko 提交于
      <controller type='pci' index='0' model='pci-root'>
        <pcihole64 unit='KiB'>1048576</pcihole64>
      </controller>
      
      It can be used to adjust (or disable) the size of the 64-bit
      PCI hole. The size attribute is in kilobytes (different unit
      can be specified on input), but it gets rounded up to
      the nearest GB by QEMU.
      
      Disabling it will be needed for guests that crash with the
      64-bit PCI hole (like Windows XP), see:
      https://bugzilla.redhat.com/show_bug.cgi?id=990418
      01cda918
  23. 21 8月, 2013 1 次提交
    • E
      selinux: distinguish failure to label from request to avoid label · 0f082e69
      Eric Blake 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=924153
      
      Commit 904e05a2 (v0.9.9) added a per-<disk> seclabel element with
      an attribute relabel='no' in order to try and minimize the
      impact of shutdown delays when an NFS server disappears.  The idea
      was that if a disk is on NFS and can't be labeled in the first
      place, there is no need to attempt the (no-op) relabel on domain
      shutdown.  Unfortunately, the way this was implemented was by
      modifying the domain XML so that the optimization would survive
      libvirtd restart, but in a way that is indistinguishable from an
      explicit user setting.  Furthermore, once the setting is turned
      on, libvirt avoids attempts at labeling, even for operations like
      snapshot or blockcopy where the chain is being extended or pivoted
      onto non-NFS, where SELinux labeling is once again possible.  As
      a result, it was impossible to do a blockcopy to pivot from an
      NFS image file onto a local file.
      
      The solution is to separate the semantics of a chain that must
      not be labeled (which the user can set even on persistent domains)
      vs. the optimization of not attempting a relabel on cleanup (a
      live-only annotation), and using only the user's explicit notation
      rather than the optimization as the decision on whether to skip
      a label attempt in the first place.  When upgrading an older
      libvirtd to a newer, an NFS volume will still attempt the relabel;
      but as the avoidance of a relabel was only an optimization, this
      shouldn't cause any problems.
      
      In the ideal future, libvirt will eventually have XML describing
      EVERY file in the backing chain, with each file having a separate
      <seclabel> element.  At that point, libvirt will be able to track
      more closely which files need a relabel attempt at shutdown.  But
      until we reach that point, the single <seclabel> for the entire
      <disk> chain is treated as a hint - when a chain has only one
      file, then we know it is accurate; but if the chain has more than
      one file, we have to attempt relabel in spite of the attribute,
      in case part of the chain is local and SELinux mattered for that
      portion of the chain.
      
      * src/conf/domain_conf.h (_virSecurityDeviceLabelDef): Add new
      member.
      * src/conf/domain_conf.c (virSecurityDeviceLabelDefParseXML):
      Parse it, for live images only.
      (virSecurityDeviceLabelDefFormat): Output it.
      (virDomainDiskDefParseXML, virDomainChrSourceDefParseXML)
      (virDomainDiskSourceDefFormat, virDomainChrDefFormat)
      (virDomainDiskDefFormat): Pass flags on through.
      * src/security/security_selinux.c
      (virSecuritySELinuxRestoreSecurityImageLabelInt): Honor labelskip
      when possible.
      (virSecuritySELinuxSetSecurityFileLabel): Set labelskip, not
      norelabel, if labeling fails.
      (virSecuritySELinuxSetFileconHelper): Fix indentation.
      * docs/formatdomain.html.in (seclabel): Document new xml.
      * docs/schemas/domaincommon.rng (devSeclabel): Allow it in RNG.
      * tests/qemuxml2argvdata/qemuxml2argv-seclabel-*-labelskip.xml:
      * tests/qemuxml2argvdata/qemuxml2argv-seclabel-*-labelskip.args:
      * tests/qemuxml2xmloutdata/qemuxml2xmlout-seclabel-*-labelskip.xml:
      New test files.
      * tests/qemuxml2argvtest.c (mymain): Run the new tests.
      * tests/qemuxml2xmltest.c (mymain): Likewise.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      0f082e69
  24. 06 8月, 2013 3 次提交
    • L
      qemu: fix handling of default/implicit devices for q35 · c27b0bb1
      Laine Stump 提交于
      This patch adds in special handling for a few devices that need to be
      treated differently for q35 domains:
      
      usb - there is no implicit/default usb controller for the q35
      machinetype. This is done because normally the default usb controller
      is added to a domain by just adding "-usb" to the qemu commandline,
      and it's assumed that this will add a single piix3 usb1 controller at
      slot 1 function 2. That's not what happens when the machinetype is
      q35, though. Instead, adding -usb to the commandline adds 3 usb
      (version 2) controllers to the domain at slot 0x1D.{1,2,7}. Rather
      than having
      
        <controller type='usb' index='0'/>
      
      translate into 3 separate devices on the PCI bus, it's cleaner to not
      automatically add a default usb device; one can always be added
      explicitly if desired. Or we may decide that on q35 machines, 3 usb
      controllers will be automatically added when none is given. But for
      this initial commit, at least we aren't locking ourselves into
      something we later won't want.
      
      video - qemu always initializes the primary video device immediately
      after any integrated devices for the machinetype. Unless instructed
      otherwise (by using "-device vga..." instead of "-vga" which libvirt
      uses in many cases to work around deficiencies and bugs in various
      qemu versions) qemu will always pick the first unused slot. In the
      case of the "pc" machinetype and its derivatives, this is always slot
      2, but on q35 machinetypes, the first free slot is slot 1 (since the
      q35's integrated peripheral devices are placed in other slots,
      e.g. slot 0x1f). In order to make the PCI address of the video device
      predictable, that slot (1 or 2, depending on machinetype) is reserved
      even when no video device has been specified.
      
      sata - a q35 machine always has a sata controller implicitly added at
      slot 0x1F, function 2. There is no way to avoid this controller, so we
      always add it. Note that the xml2xml tests for the pcie-root and q35
      cases were changed to use DO_TEST_DIFFERENT() so that we can check for
      the sata controller being automatically added. This is especially
      important because we can't check for it in the xml2argv output (it has
      no effect on that output since it's an implicit device).
      
      ide - q35 has no ide controllers.
      
      isa and smbus controllers - these two are always present in a q35 (at
      slot 0x1F functions 0 and 3) but we have no way of modelling them in
      our config. We do need to reserve those functions so that the user
      doesn't attempt to put anything else there though. (note that the "pc"
      machine type also has an ISA controller, which we also ignore).
      c27b0bb1
    • L
      qemu: add dmi-to-pci-bridge controller · 62ac6b43
      Laine Stump 提交于
      This PCI controller, named "dmi-to-pci-bridge" in the libvirt config,
      and implemented with qemu's "i82801b11-bridge" device, connects to a
      PCI Express slot (e.g. one of the slots provided by the pcie-root
      controller, aka "pcie.0" on the qemu commandline), and provides 31
      *non-hot-pluggable* PCI (*not* PCIe) slots, numbered 1-31.
      
      Any time a machine is defined which has a pcie-root controller
      (i.e. any q35-based machinetype), libvirt will automatically add a
      dmi-to-pci-bridge controller if one doesn't exist, and also add a
      pci-bridge controller. The reasoning here is that any useful domain
      will have either an immediate (startup time) or eventual (subsequent
      hot-plug) need for a standard PCI slot; since the pcie-root controller
      only provides PCIe slots, we need to connect a dmi-to-pci-bridge
      controller to it in order to get a non-hot-plug PCI slot that we can
      then use to connect a pci-bridge - the slots provided by the
      pci-bridge will be both standard PCI and hot-pluggable.
      
      Since pci-bridge devices themselves can not be hot-plugged into a
      running system (although you can hot-plug other devices into a
      pci-bridge's slots), any new pci-bridge controller that is added can
      (and will) be plugged into the dmi-to-pci-bridge as long as it has
      empty slots available.
      
      This patch is also changing the qemuxml2xml-pcie test from a "DO_TEST"
      to a "DO_DIFFERENT_TEST". This is so that the "before" xml can omit
      the automatically added dmi-to-pci-bridge and pci-bridge devices, and
      the "after" xml can include it - this way we are testing if libvirt is
      properly adding these devices.
      62ac6b43
    • L
      qemu: add pcie-root controller · 48a3f48a
      Laine Stump 提交于
      This controller is implicit on q35 machinetypes. It provides 31 PCIe
      (*not* PCI) slots as controller 0.
      
      Currently there are no devices that can connect to pcie-root, and no
      implicit pci controller on a q35 machine, so q35 is still
      unusable. For a usable q35 system, we need to add a
      "dmi-to-pci-bridge" pci controller, which can connect to pcie-root,
      and provides standard pci slots that can be used to connect other
      devices.
      48a3f48a
  25. 24 7月, 2013 1 次提交
    • L
      qemu: set/validate slot/connection type when assigning slots for PCI devices · 3ceb4c7d
      Laine Stump 提交于
      Since PCI bridges, PCIe bridges, PCIe switches, and PCIe root ports
      all share the same namespace, they are all defined as controllers of
      type='pci' in libvirt (but with a differing model attribute). Each of
      these controllers has a certain connection type upstream, allows
      certain connection types downstream, and each can either allow a
      single downstream connection at slot 0, or connections from slot 1 -
      31.
      
      Right now, we only support the pci-root and pci-bridge devices, both
      of which only allow PCI devices to connect, and both which have usable
      slots 1 - 31. In preparation for adding other types of controllers
      that have different capabilities, this patch 1) adds info to the
      qemuDomainPCIAddressBus object to indicate the capabilities, 2) sets
      those capabilities appropriately for pci-root and pci-bridge devices,
      and 3) validates that the controller being connected to is the proper
      type when allocating slots or validating that a user-selected slot is
      appropriate for a device..
      
      Having this infrastructure in place will make it much easier to add
      support for the other PCI controller types.
      
      While it would be possible to do all the necessary checking by just
      storing the controller model in the qemyuDomainPCIAddressBus, it
      greatly simplifies all the validation code to also keep a "flags",
      "minSlot" and "maxSlot" for each - that way we can just check those
      attributes rather than requiring a nearly identical switch statement
      everywhere we need to validate compatibility.
      
      You may notice many places where the flags are seemingly hard-coded to
      
        QEMU_PCI_CONNECT_HOTPLUGGABLE | QEMU_PCI_CONNECT_TYPE_PCI
      
      This is currently the correct value for all PCI devices, and in the
      future will be the default, with small bits of code added to change to
      the flags for the few devices which are the exceptions to this rule.
      
      Finally, there are a few places with "FIXME" comments. Note that these
      aren't indicating places that are broken according to the currently
      supported devices, they are places that will need fixing when support
      for new PCI controller models is added.
      
      To assure that there was no regression in the auto-allocation of PCI
      addresses or auto-creation of integrated pci-root, ide, and usb
      controllers, a new test case (pci-bridge-many-disks) has been added to
      both the qemuxml2argv and qemuxml2xml tests. This new test defines a
      domain with several dozen virtio disks but no pci-root or
      pci-bridges. The .args file of the new test case was created using
      libvirt sources from before this patch, and the test still passes
      after this patch has been applied.
      3ceb4c7d
  26. 23 7月, 2013 1 次提交
    • J
      conf: Introduce new XML tag "mode" for disk source · c00b2f0d
      John Ferlan 提交于
      There are two ways to use a iSCSI LUN as disk source for qemu.
      
       * The LUN's path as it shows up on host, e.g.
         /dev/disk/by-path/ip-$ip:3260-iscsi-$iqn-fc18:iscsi.iscsi0-lun-1
      
       * The libiscsi URI from the storage pool source element host attribute, e.g.
         iscsi://demo.org:6000/iqn.1992-01.com.example/1
      
      For a "volume" type disk, if the specified "pool" is of iscsi
      type, we should support to use the LUN in either of above 2 ways.
      That's why to introduce a new XML tag "mode" for the disk source
      (libvirt should support iscsi pool with libiscsi, but it's another
      new feature, which should be done later).
      
      The "mode" can be either of "host" or "direct". Use "host" to indicate
      use of the LUN with the path as it shows up on host. Use "direct" to
      indicate to use it with the source pool host URI (future patches may support
      to use network type libvirt storage too, e.g. Ceph)
      c00b2f0d
  27. 10 7月, 2013 1 次提交
    • M
      Introduce OOM reporting to virAsprintf · dc6f2dad
      Michal Privoznik 提交于
      Actually, I'm turning this function into a macro as filename,
      function name and line number needs to be passed. The new
      function virAsprintfInternal is introduced with the extended set
      of arguments.
      dc6f2dad
  28. 05 7月, 2013 1 次提交
  29. 28 6月, 2013 1 次提交
  30. 01 6月, 2013 1 次提交
    • O
      conf: Generate address for scsi host device automatically · cdb97895
      Osier Yang 提交于
      With unknown good reasons, the attribute "bus" of scsi device
      address is always set to 0, same for attribute "target". (See
      virDomainDiskDefAssignAddress).
      
      Though we might need to change the algorithm to honor "bus"
      and "target" too, that's a different issue. The address generator
      for scsi host device in this patch just follows the unknown
      good reasons, only considering the "controller" and "unit".
      It walks through all scsi controllers and their units, to see
      if the address $controller:0:0:$unit can be used (if not used
      by any disk or scsi host device yet), if found one, it sits on
      it, otherwise, it creates a new controller (actually the controller
      is implicitly created by someone else), and sits on
      $new_controller:0:0:0 instead.
      cdb97895