1. 02 8月, 2016 17 次提交
  2. 01 8月, 2016 2 次提交
  3. 29 7月, 2016 1 次提交
    • M
      conf: Catch invalid memory model earlier · 1e058463
      Michal Privoznik 提交于
      Consider the following XML snippet:
      
          <memory model=''>
            <target>
              <size unit='KiB'>523264</size>
              <node>0</node>
            </target>
          </memory>
      
      Whats wrong you ask? The @model attribute. This should result in
      an error thrown into users faces during virDomainDefine phase.
      Except it doesn't. The XML validation catches this error, but if
      users chose to ignore that, they will end up with invalid XML.
      Well, they won't be able to start the machine - that's when error
      is produced currently. But it would be nice if we could catch the
      error like this earlier.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      1e058463
  4. 28 7月, 2016 2 次提交
    • J
      qemu: Need to free fileprops in error path · 8ad7eceb
      John Ferlan 提交于
      The virJSONValueObjectCreate only consumes the object on success, so on
      failure we must free - from commit id 'f4441017' (found by Coverity).
      8ad7eceb
    • 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
  5. 27 7月, 2016 12 次提交
  6. 26 7月, 2016 6 次提交