1. 31 1月, 2018 9 次提交
  2. 30 1月, 2018 9 次提交
  3. 29 1月, 2018 17 次提交
  4. 26 1月, 2018 5 次提交
    • Z
      vhost-user: add support reconnect for vhost-user ports · 614be3b8
      ZhiPeng Lu 提交于
      For vhost-user ports, Open vSwitch acts as the server and QEMU the client.
      When OVS crashes or restarts, the QEMU process should be reconnected to
      OVS.
      Signed-off-by: NZhiPeng Lu <lu.zhipeng@zte.com.cn>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      614be3b8
    • J
      docs: Add missing element encryption description term entry · 6aba0715
      John Ferlan 提交于
      Missed adding the "encryption" description term entry to the list
      of possible sub-elements for disk source. The description details
      were there, just not the tag.
      6aba0715
    • D
      resctl: stub out functions with Linux-only APIs used · a020ab03
      Daniel P. Berrangé 提交于
      The flock() function and d_type field in struct dirent are not portable
      to the mingw platform.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      a020ab03
    • D
      rpc: fix race sending and encoding sasl data · 4e13fb02
      Daniel P. Berrange 提交于
      The virNetSocketWriteSASL method has to encode the buffer it is given and then
      write it to the underlying socket. This write is not guaranteed to send the
      full amount of data that was encoded by SASL. We cache the SASL encoded data so
      that on the next invocation of virNetSocketWriteSASL we carry on sending it.
      
      The subtle problem is that the 'len' value passed into virNetSocketWriteSASL on
      the 2nd call may be larger than the original value. So when we've completed
      sending the SASL encoded data we previously cached, we must return the original
      length we encoded, not the new length.
      
      This flaw means we could potentially have been discarded queued data without
      sending it. This would have exhibited itself as a libvirt client never receiving
      the reply to a method it invokes, async events silently going missing, or worse
      stream data silently getting dropped.
      
      For this to be a problem libvirtd would have to be queued data to send to the
      client, while at the same time the TCP socket send buffer is full (due to a very
      slow client). This is quite unlikely so if this bug was ever triggered by a real
      world user it would be almost impossible to reproduce or diagnose, if indeed it
      was ever noticed at all.
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      4e13fb02
    • J
      libxl: resume lock process after failed migration · 0c710a37
      Jim Fehlig 提交于
      During migration, the lock process is paused in the perform phase
      but not resumed if there is a subsequent failure, leaving the locked
      resource unprotected.
      
      The perform phase itself can fail, in which case the lock process
      should be resumed before returning from perform. The finish phase
      could also fail on the destination host, in which case the migration
      is canceled in the confirm phase and the VM is resumed. The lock
      process needs to be resumed there as well.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      0c710a37