All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [Bug 1450891] [NEW] VM will not resume on GlusterFS
@ 2015-05-01 19:24 Christopher Pereira
  2015-05-04 11:27 ` [Qemu-devel] [Bug 1450891] " Kevin Wolf
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Christopher Pereira @ 2015-05-01 19:24 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

oVirt uses libvirt to run QEMU.
Images are passed to QEMU as files, not file descriptors.
When running images from a GlusterFS, the file descriptors may get invalidated because of network problems or the glusterfs process being restarted.
In this case, the VM goes into paused state.
When trying to resume the VM ('cont' command), QEMU uses the same invalidated file descriptors throwing a:
"block I/O error in device 'drive-virtio-disk0': Transport endpoint is not connected (107)".

Please check file-descriptors and reopen image file on 'cont' event in QEMU.
Thanks.

References:

[1] http://lists.nongnu.org/archive/html/qemu-devel/2015-03/msg01269.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1058300

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1450891

Title:
  VM will not resume on GlusterFS

Status in QEMU:
  New

Bug description:
  oVirt uses libvirt to run QEMU.
  Images are passed to QEMU as files, not file descriptors.
  When running images from a GlusterFS, the file descriptors may get invalidated because of network problems or the glusterfs process being restarted.
  In this case, the VM goes into paused state.
  When trying to resume the VM ('cont' command), QEMU uses the same invalidated file descriptors throwing a:
  "block I/O error in device 'drive-virtio-disk0': Transport endpoint is not connected (107)".

  Please check file-descriptors and reopen image file on 'cont' event in QEMU.
  Thanks.

  References:

  [1] http://lists.nongnu.org/archive/html/qemu-devel/2015-03/msg01269.html
  [2] https://bugzilla.redhat.com/show_bug.cgi?id=1058300

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1450891/+subscriptions

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Qemu-devel] [Bug 1450891] Re: VM will not resume on GlusterFS
  2015-05-01 19:24 [Qemu-devel] [Bug 1450891] [NEW] VM will not resume on GlusterFS Christopher Pereira
@ 2015-05-04 11:27 ` Kevin Wolf
  2015-05-04 22:00 ` Christopher Pereira
  2018-05-07 19:47 ` Thomas Huth
  2 siblings, 0 replies; 4+ messages in thread
From: Kevin Wolf @ 2015-05-04 11:27 UTC (permalink / raw)
  To: qemu-devel

We can't just reopen files, we don't know what state they are in. Any
data that has been written to the image between the last flush and the
point where gluster made the fd invalid may be there or may be missing.
If any data is missing, we can't continue the guest or you'll get data
corruption.

The correct fix for resuming after I/O errors is on gluster. As long as
it invalidates the fd, without a way to resume, there is no way for qemu
to correctly continue after an error.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1450891

Title:
  VM will not resume on GlusterFS

Status in QEMU:
  New

Bug description:
  oVirt uses libvirt to run QEMU.
  Images are passed to QEMU as files, not file descriptors.
  When running images from a GlusterFS, the file descriptors may get invalidated because of network problems or the glusterfs process being restarted.
  In this case, the VM goes into paused state.
  When trying to resume the VM ('cont' command), QEMU uses the same invalidated file descriptors throwing a:
  "block I/O error in device 'drive-virtio-disk0': Transport endpoint is not connected (107)".

  Please check file-descriptors and reopen image file on 'cont' event in QEMU.
  Thanks.

  References:

  [1] http://lists.nongnu.org/archive/html/qemu-devel/2015-03/msg01269.html
  [2] https://bugzilla.redhat.com/show_bug.cgi?id=1058300

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1450891/+subscriptions

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Qemu-devel] [Bug 1450891] Re: VM will not resume on GlusterFS
  2015-05-01 19:24 [Qemu-devel] [Bug 1450891] [NEW] VM will not resume on GlusterFS Christopher Pereira
  2015-05-04 11:27 ` [Qemu-devel] [Bug 1450891] " Kevin Wolf
@ 2015-05-04 22:00 ` Christopher Pereira
  2018-05-07 19:47 ` Thomas Huth
  2 siblings, 0 replies; 4+ messages in thread
From: Christopher Pereira @ 2015-05-04 22:00 UTC (permalink / raw)
  To: qemu-devel

Hi Kevin,

I understand. In this case (where the gluster process was killed or
crashed) I guess the best option would be to poweroff and restart the
VM, which can be done client-side (ovirt + libvirt)

Please mark as "Won't fix".

Thanks.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1450891

Title:
  VM will not resume on GlusterFS

Status in QEMU:
  New

Bug description:
  oVirt uses libvirt to run QEMU.
  Images are passed to QEMU as files, not file descriptors.
  When running images from a GlusterFS, the file descriptors may get invalidated because of network problems or the glusterfs process being restarted.
  In this case, the VM goes into paused state.
  When trying to resume the VM ('cont' command), QEMU uses the same invalidated file descriptors throwing a:
  "block I/O error in device 'drive-virtio-disk0': Transport endpoint is not connected (107)".

  Please check file-descriptors and reopen image file on 'cont' event in QEMU.
  Thanks.

  References:

  [1] http://lists.nongnu.org/archive/html/qemu-devel/2015-03/msg01269.html
  [2] https://bugzilla.redhat.com/show_bug.cgi?id=1058300

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1450891/+subscriptions

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Qemu-devel] [Bug 1450891] Re: VM will not resume on GlusterFS
  2015-05-01 19:24 [Qemu-devel] [Bug 1450891] [NEW] VM will not resume on GlusterFS Christopher Pereira
  2015-05-04 11:27 ` [Qemu-devel] [Bug 1450891] " Kevin Wolf
  2015-05-04 22:00 ` Christopher Pereira
@ 2018-05-07 19:47 ` Thomas Huth
  2 siblings, 0 replies; 4+ messages in thread
From: Thomas Huth @ 2018-05-07 19:47 UTC (permalink / raw)
  To: qemu-devel

Marking as "Won't Fix" according to the last comment.

** Changed in: qemu
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1450891

Title:
  VM will not resume on GlusterFS

Status in QEMU:
  Won't Fix

Bug description:
  oVirt uses libvirt to run QEMU.
  Images are passed to QEMU as files, not file descriptors.
  When running images from a GlusterFS, the file descriptors may get invalidated because of network problems or the glusterfs process being restarted.
  In this case, the VM goes into paused state.
  When trying to resume the VM ('cont' command), QEMU uses the same invalidated file descriptors throwing a:
  "block I/O error in device 'drive-virtio-disk0': Transport endpoint is not connected (107)".

  Please check file-descriptors and reopen image file on 'cont' event in QEMU.
  Thanks.

  References:

  [1] http://lists.nongnu.org/archive/html/qemu-devel/2015-03/msg01269.html
  [2] https://bugzilla.redhat.com/show_bug.cgi?id=1058300

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1450891/+subscriptions

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2018-05-07 20:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-01 19:24 [Qemu-devel] [Bug 1450891] [NEW] VM will not resume on GlusterFS Christopher Pereira
2015-05-04 11:27 ` [Qemu-devel] [Bug 1450891] " Kevin Wolf
2015-05-04 22:00 ` Christopher Pereira
2018-05-07 19:47 ` Thomas Huth

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.