1. 04 8月, 2016 8 次提交
  2. 03 8月, 2016 1 次提交
    • J
      conf: Add IOThread quota and period scheduler/cputune defs · 2197ea56
      John Ferlan 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1356937
      
      Add the definitions to allow for viewing/setting cgroup period and quota
      limits for IOThreads.
      
      This is similar to the work done for emulator quota and period by
      commit ids 'b65dafa8' and 'e051c482'.
      
      Being able to view/set the IOThread specific values is related to more
      recent changes adding global period (commmit id '4d92d58f') and global
      quota (commit id '55ecdae0') definitions and qemu support (commit id
      '4e17ff79' and 'fbcbd1b2'). With a global setting though, if somehow
      the IOThread value in the cgroup hierarchy was set "outside of libvirt"
      to a value that is incompatible with the global value.
      
      Allowing control over IOThread specific values provides the capability
      to alter the IOThread values as necessary.
      2197ea56
  3. 02 8月, 2016 4 次提交
  4. 01 8月, 2016 1 次提交
    • P
      tests: qemu: Don't leak security manager object · 71d341e7
      Peter Krempa 提交于
      ==2064442== 200 (88 direct, 112 indirect) bytes in 1 blocks are definitely lost in loss record 54 of 73
      ==2064442==    at 0x4C2E0F0: calloc (vg_replace_malloc.c:711)
      ==2064442==    by 0x18E75B80: virAllocVar (viralloc.c:560)
      ==2064442==    by 0x18EC43B0: virObjectNew (virobject.c:193)
      ==2064442==    by 0x18EC476E: virObjectLockableNew (virobject.c:219)
      ==2064442==    by 0x1906BC73: virSecurityManagerNewDriver (security_manager.c:93)
      ==2064442==    by 0x1906C076: virSecurityManagerNewStack (security_manager.c:115)
      ==2064442==    by 0x43CC39: qemuTestDriverInit (testutilsqemu.c:548)
      ==2064442==    by 0x4337ED: mymain (qemumonitorjsontest.c:2440)
      ==2064442==    by 0x43BABE: virTestMain (testutils.c:982)
      ==2064442==    by 0x43A490: main (qemumonitorjsontest.c:2558)
      71d341e7
  5. 28 7月, 2016 1 次提交
    • D
      storage: remove "luks" storage volume type · a48c7141
      Daniel P. Berrange 提交于
      The current LUKS support has a "luks" volume type which has
      a "luks" encryption format.
      
      This partially makes sense if you consider the QEMU shorthand
      syntax only requires you to specify a format=luks, and it'll
      automagically uses "raw" as the next level driver. QEMU will
      however let you override the "raw" with any other driver it
      supports (vmdk, qcow, rbd, iscsi, etc, etc)
      
      IOW the intention though is that the "luks" encryption format
      is applied to all disk formats (whether raw, qcow2, rbd, gluster
      or whatever). As such it doesn't make much sense for libvirt
      to say the volume type is "luks" - we should be saying that it
      is a "raw" file, but with "luks" encryption applied.
      
      IOW, when creating a storage volume we should use this XML
      
        <volume>
          <name>demo.raw</name>
          <capacity>5368709120</capacity>
          <target>
            <format type='raw'/>
            <encryption format='luks'>
              <secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/>
            </encryption>
          </target>
        </volume>
      
      and when configuring a guest disk we should use
      
        <disk type='file' device='disk'>
          <driver name='qemu' type='raw'/>
          <source file='/home/berrange/VirtualMachines/demo.raw'/>
          <target dev='sda' bus='scsi'/>
          <encryption format='luks'>
            <secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/>
          </encryption>
        </disk>
      
      This commit thus removes the "luks" storage volume type added
      in
      
        commit 318ebb36
        Author: John Ferlan <jferlan@redhat.com>
        Date:   Tue Jun 21 12:59:54 2016 -0400
      
          util: Add 'luks' to the FileTypeInfo
      
      The storage file probing code is modified so that it can probe
      the actual encryption formats explicitly, rather than merely
      probing existance of encryption and letting the storage driver
      guess the format.
      
      The rest of the code is then adapted to deal with
      VIR_STORAGE_FILE_RAW w/ VIR_STORAGE_ENCRYPTION_FORMAT_LUKS
      instead of just VIR_STORAGE_FILE_LUKS.
      
      The commit mentioned above was included in libvirt v2.0.0.
      So when querying volume XML this will be a change in behaviour
      vs the 2.0.0 release - it'll report 'raw' instead of 'luks'
      for the volume format, but still report 'luks' for encryption
      format.  I think this change is OK because the storage driver
      did not include any support for creating volumes, nor starting
      guets with luks volumes in v2.0.0 - that only since then.
      Clearly if we change this we must do it before v2.1.0 though.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      a48c7141
  6. 27 7月, 2016 16 次提交
  7. 25 7月, 2016 1 次提交
    • T
      qemuhotplugtest: Add tests for ccw devices · ed8f2364
      Tomasz Flendrich 提交于
      There's a plan to rework the address handling, so testcases
      that verify hotplugging ccw devices will help in avoiding
      regression.
      
      In this commit, some files are duplicated because of the way
      qemuhotplug.c calculates the expected xml filenames.
      I plan on changing that to explicitly stating the basis domain
      xml, the device xml, and the expected xml.
      ed8f2364
  8. 21 7月, 2016 5 次提交
  9. 20 7月, 2016 1 次提交
    • J
      qemu: Disallow usage of luks encryption if aes secret not possible · a53349e6
      John Ferlan 提交于
      Resolves a CI test integration failure with a RHEL6/Centos6 environment.
      
      In order to use a LUKS encrypted device, the design decision was to
      generate an encrypted secret based on the master key. However, commit
      id 'da86c6c2' missed checking for that specifically.
      
      When qemuDomainSecretSetup was implemented, a design decision was made
      to "fall back" to a plain text secret setup if the specific cipher was
      not available (e.g. virCryptoHaveCipher(VIR_CRYPTO_CIPHER_AES256CBC))
      as well as the QEMU_CAPS_OBJECT_SECRET. For the luks encryption setup
      there is no fall back to the plaintext secret, thus if that gets set
      up by qemuDomainSecretSetup, then we need to fail.
      
      Also, while the qemuxml2argvtest has set the QEMU_CAPS_OBJECT_SECRET
      bit, it didn't take into account the second requirement that the
      ability to generate the encrypted secret is possible. So modify the
      test to not attempt to run the luks-disk if we know we don't have
      the encryption algorithm.
      a53349e6
  10. 19 7月, 2016 2 次提交
    • J
      qemu: Add luks support for domain disk · da86c6c2
      John Ferlan 提交于
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1301021
      
      Generate the luks command line using the AES secret key to encrypt the
      luks secret. A luks secret object will be in addition to a an AES secret.
      
      For hotplug, check if the encinfo exists and if so, add the AES secret
      for the passphrase for the secret object used to decrypt the device.
      
      Modify/augment the fakeSecret* in qemuxml2argvtest in order to handle
      find a uuid or a volume usage with a specific path prefix in the XML
      (corresponds to the already generated XML tests). Add error message
      when the 'usageID' is not 'mycluster_myname'. Commit id '1d632c39'
      altered the error message generation to rely on the errors from the
      secret_driver (or it's faked replacement).
      
      Add the .args output for adding the LUKS disk to the domain
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      da86c6c2
    • J
      storage: Add support to create a luks volume · 5e46d7d6
      John Ferlan 提交于
      Partially resolves:
      https://bugzilla.redhat.com/show_bug.cgi?id=1301021
      
      If the volume xml was looking to create a luks volume take the necessary
      steps in order to make that happen.
      
      The processing will be:
       1. create a temporary file (virStorageBackendCreateQemuImgSecretPath)
         1a. use the storage driver state dir path that uses the pool and
             volume name as a base.
      
       2. create a secret object (virStorageBackendCreateQemuImgSecretObject)
         2a. use an alias combinding the volume name and "_luks0"
         2b. add the file to the object
      
       3. create/add luks options to the commandline (virQEMUBuildLuksOpts)
         3a. at the very least a "key-secret=%s" using the secret object alias
         3b. if found in the XML the various "cipher" and "ivgen" options
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      5e46d7d6