Bug 736631
Summary: | qemu crashes if screen dump is called when the vm is stopped | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Golita Yue <gyue> | |
Component: | spice-server | Assignee: | Yonit Halperin <yhalperi> | |
Status: | CLOSED NOTABUG | QA Contact: | Desktop QE <desktop-qa-list> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 6.2 | CC: | acathrow, alevy, bcao, cfergeau, dblechte, juzhang, kraxel, michen, mkenneth, mkrcmari, pvine, shuang, tburke, virt-maint, xwei | |
Target Milestone: | rc | Keywords: | Reopened | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 748810 (view as bug list) | Environment: | ||
Last Closed: | 2012-02-15 15:08:27 UTC | Type: | --- | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 748810, 798195 |
Description
Golita Yue
2011-09-08 10:22:26 UTC
Hit this bug in the following cases respectively: 1. stop/continue 2. migrate to file 3. live migrate during reboot testing host info: spice-server-0.8.2-3.el6.x86_64 Moving to spice owners, please test w/o spice/qxl too. Already created four jobs with vnc to retest this bug. I will update the test result when job finished. Can you provide backtrace of all threads, not just the crashing thread? I suspect this has something to do with an io write after vm stop. This seems like a duplicate of rhbz#729621. Please provide qemu-kvm output. Does it contain a line with "ASSERT worker->running failed" ? (In reply to comment #5) > Already created four jobs with vnc to retest this bug. > I will update the test result when job finished. Tested with vnc, didn't hit qemu crash, passed. the job link: https://virtlab.englab.nay.redhat.com/job/38140/details/ https://virtlab.englab.nay.redhat.com/job/38139/details/ https://virtlab.englab.nay.redhat.com/job/38137/details/ https://virtlab.englab.nay.redhat.com/job/38136/details/ (In reply to comment #7) > This seems like a duplicate of rhbz#729621. > Please provide qemu-kvm output. > Does it contain a line with "ASSERT worker->running failed" ? Yes, hit above line. (qemu) handle_dev_update: ASSERT worker->running failed (qemu) /bin/sh: line 1: 13568 Aborted (qemu) (Process terminated with status 134) If you think this is duplicate of rhbz#729621. Please close this bug, thanks. Since this issue component is changed form qemu-kvm to spice-server,reset qa_ack to ? Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. proposed to 6.3 based on comment 11. *** This bug has been marked as a duplicate of bug 729621 *** Options for solution: (1) If screen_dump occurs when the vm is stopped, qxl will return an empty screen dump. (2) Different api for screen_dumps requests (or an additional flag to update_area). And when we receive screen dump request, we return the screen dump according to the latest spice server state, which can be older than the one of the device. (3) Holding a flag that indicates if it is o.k to access the guest memory. This flag will be false between pre_load and post_load. We will allow screen_dumps when the flag is true (don't think screen dumps are even possible otherwise since the migration target is blocked). Still I think we need a different api for screen_dumps, since calls for update_area should be triggered from the vm when it is stopped. (4) upon stopping the vm, reading and emptying the command rings. If a client is connected, the time it will take to empty the command ring, depends on sending all the commands to the client (or a timeout), and it will affect migration. Then, when we receive an update_area command, we don't need to read the command rings. CC'ing gerd for comments. (In reply to comment #19) > Options for solution: > (1) If screen_dump occurs when the vm is stopped, qxl will return an empty > screen dump. Not an option, misleading to users. > (2) > Different api for screen_dumps requests (or an additional flag to update_area). > And when we receive screen dump request, we return the screen dump according to > the latest spice server state, which can be older than the one of the device. > (3) Holding a flag that indicates if it is o.k to access the guest memory. This > flag will be false between pre_load and post_load. We will allow screen_dumps > when the flag is true (don't think screen dumps are even possible otherwise > since the migration target is blocked). I think so too. Not sure if this is something we can rely on to stay in the future. > Still I think we need a different api for screen_dumps, since calls for > update_area should be triggered from the vm when it is stopped. The right thing to do seems to me is to read the command ring (if we can, with the flag) and not to force the to-client pipe size to be bounded. With the current implementation that would mean we may cross the 50 items in the outgoing pipe. I think it would still be ok, since the next update to the client (not a screen_dump or update_area if we keep the old api) will flush it. > (4) upon stopping the vm, reading and emptying the command rings. If a client > is connected, the time it will take to empty the command ring, depends on > sending all the commands to the client (or a timeout), and it will affect > migration. Then, when we receive an update_area command, we don't need to read > the command rings. Unbounded time to complete, not a good idea. > > > CC'ing gerd for comments. (In reply to comment #20) > (In reply to comment #19) > > Options for solution: > > (1) If screen_dump occurs when the vm is stopped, qxl will return an empty > > screen dump. > > Not an option, misleading to users. > > > (2) > > Different api for screen_dumps requests (or an additional flag to update_area). > > And when we receive screen dump request, we return the screen dump according to > > the latest spice server state, which can be older than the one of the device. > > (3) Holding a flag that indicates if it is o.k to access the guest memory. This > > flag will be false between pre_load and post_load. We will allow screen_dumps > > when the flag is true (don't think screen dumps are even possible otherwise > > since the migration target is blocked). > > I think so too. Not sure if this is something we can rely on to stay in the > future. > > > Still I think we need a different api for screen_dumps, since calls for > > update_area should be triggered from the vm when it is stopped. > > The right thing to do seems to me is to read the command ring (if we can, with > the flag) and not to force the to-client pipe size to be bounded. With the > current implementation that would mean we may cross the 50 items in the > outgoing pipe. I think it would still be ok, since the next update to the > client (not a screen_dump or update_area if we keep the old api) will flush it. > IMHO, the issue of limiting the pipe size is not related to this bug. The pipe limit affects each update area, and not only the ones triggered from screen dump. The limit exists in order not to overflow the device memory, and we know it should be changed to be more smart than 50 items. But I think it is not in this bug scope. > > (4) upon stopping the vm, reading and emptying the command rings. If a client > > is connected, the time it will take to empty the command ring, depends on > > sending all the commands to the client (or a timeout), and it will affect > > migration. Then, when we receive an update_area command, we don't need to read > > the command rings. > > Unbounded time to complete, not a good idea. I don't like it as well, but I presented it since it is simple. > > > > > > > CC'ing gerd for comments. Hi Golita, can you also attach the qemu output log? Thanks, Yonit. Hi Yonit, Please refer to comment #9 for qemu output log. b.r. Golita I'm closing this bug since its fix is in qemu-kvm and doesn't involve spice-server (bug 748810) |