1. 03 5月, 2017 5 次提交
    • A
      news: Add more v3.3.0 entries · 624bc926
      Andrea Bolognani 提交于
      These entries cover a number of features, improvements and
      bug fixes that had not been documented during the development
      cycle.
      624bc926
    • A
      news: Tweak existing v3.3.0 entries · 0d309813
      Andrea Bolognani 提交于
      Some of the content was not following the (loosely established)
      style, and some of the XML was not aligned properly.
      0d309813
    • J
      client: Report proper close reason · 42faf316
      Jiri Denemark 提交于
      When we get a POLLHUP or VIR_EVENT_HANDLE_HANGUP event for a client, we
      still want to read from the socket to process any accumulated data. But
      doing so inevitably results in an error and a call to
      virNetClientMarkClose before we get to processing the hangup event (and
      another call to virNetClientMarkClose). However the close reason passed
      to the second virNetClientMarkClose call is ignored because another one
      was already set. We need to pass the correct close reason when marking
      the socket to be closed for the first time.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1373859Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      42faf316
    • J
      qemu: Fix persistent migration of transient domains · 59307fad
      Jiri Denemark 提交于
      While fixing a bug with incorrectly freed memory in commit
      v3.1.0-399-g5498aa29, I accidentally broke persistent migration of
      transient domains. Before adding qemuDomainDefCopy in the path, the code
      just took NULL from vm->newDef and used it as the persistent def, which
      resulted in no persistent XML being sent in the migration cookie. This
      scenario is perfectly valid and the destination correctly handles it by
      using the incoming live definition and storing it as the persistent one.
      
      After the mentioned commit libvirtd would just segfault in the described
      scenario.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1446205Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      59307fad
    • D
      Fix padding of encrypted data · 71890992
      Daniel P. Berrange 提交于
      If we are encoding a block of data that is 16 bytes in length,
      we cannot leave it as 16 bytes, we must pad it out to the next
      block boundary, 32 bytes. Without this padding, the decoder will
      incorrectly treat the last byte of plain text as the padding
      length, as it can't distinguish padded from non-padded data.
      
      The problem exhibited itself when using a 16 byte passphrase
      for a LUKS volume
      
        $ virsh secret-set-value 55806c7d-8e93-456f-829b-607d8c198367 \
             $(echo -n 1234567812345678 | base64)
        Secret value set
      
        $ virsh start demo
        error: Failed to start domain demo
        error: internal error: process exited while connecting to monitor: >>>>>>>>>>Len 16
        2017-05-02T10:35:40.016390Z qemu-system-x86_64: -object \
          secret,id=virtio-disk1-luks-secret0,data=SEtNi5vDUeyseMKHwc1c1Q==,\
          keyid=masterKey0,iv=zm7apUB1A6dPcH53VW960Q==,format=base64: \
          Incorrect number of padding bytes (56) found on decrypted data
      
      Notice how the padding '56' corresponds to the ordinal value of
      the character '8'.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      71890992
  2. 02 5月, 2017 2 次提交
  3. 28 4月, 2017 33 次提交