From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmwAS-0001vA-Sv for qemu-devel@nongnu.org; Mon, 27 Apr 2015 23:26:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmwAP-0005on-Hd for qemu-devel@nongnu.org; Mon, 27 Apr 2015 23:26:40 -0400 Received: from e23smtp05.au.ibm.com ([202.81.31.147]:55676) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmwAO-0005oW-UT for qemu-devel@nongnu.org; Mon, 27 Apr 2015 23:26:37 -0400 Received: from /spool/local by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 28 Apr 2015 13:26:34 +1000 Received: from d23relay06.au.ibm.com (d23relay06.au.ibm.com [9.185.63.219]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id 557EE2BB0047 for ; Tue, 28 Apr 2015 13:26:30 +1000 (EST) Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay06.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t3S3QLHV20775016 for ; Tue, 28 Apr 2015 13:26:30 +1000 Received: from d23av03.au.ibm.com (localhost [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t3S3PuE3023199 for ; Tue, 28 Apr 2015 13:25:56 +1000 Message-ID: <553EFDB3.6000705@linux.vnet.ibm.com> Date: Tue, 28 Apr 2015 11:25:39 +0800 From: tu bo MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] qcow2 problem: while a qcow2 image run out of disk space the guest paused List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Alexandre DERUMIER , borntraeger@de.ibm.com, Holger Wolf , mimu@linux.vnet.ibm.com, qemu-devel , stefanha Dears, Xiao Guang Chen left IBM last week, and I changed owner from XiangGuang to me for this issue. XiaoGuang told me this is by design, and probably I can close it if no news. My understanding is that I can close it now. If I'm wrong, please correct me. thanks a lot From: Kevin Wolf To: Alexandre DERUMIER Cc: chenxg , stefanha , mimu@linux.vnet.ibm.com, Bo Tu/China/IBM@IBMCN, borntraeger@de.ibm.com, Holger Wolf , qemu-devel Date: 04/17/2015 03:57 PM Subject: Re: [Qemu-devel] qcow2 problem: while a qcow2 image run out of disk space the guest paused. Am 17.04.2015 um 06:30 hat Alexandre DERUMIER geschrieben: > Hi, > > Isn't it related to drive options ? > > > " > werror=action,rerror=action > > Specify which action to take on write and read errors. Valid actions are: “ignore” (ignore the error and try to continue), “stop” (pause QEMU), “report” (report the error to the guest), “enospc” (pause QEMU only if the host disk is full; report the error to the guest otherwise). The default setting is werror=enospc and rerror=report. > " Yes, it is. Generally you don't want to report such errors to the guest, because the guest sees that the disk is broken and stops using it. Even if you free some space, you wouldn't easily get the guest to use the disk again without rebooting. But if you really want, you can configure it so. It is not expected that the guest gets I/O errors (except possibly network timeouts if the VM is stopped for too long) or even qemu crashes. If it crashes again for you, please provide a gdb backtrace. Kevin > ----- Mail original ----- > De: "chenxg" > À: "Kevin Wolf" , "stefanha" , mimu@linux.vnet.ibm.com, tubo@cn.ibm.com, borntraeger@de.ibm.com, "Holger Wolf" , "qemu-devel" > Envoyé: Vendredi 17 Avril 2015 04:22:57 > Objet: [Qemu-devel] qcow2 problem: while a qcow2 image run out of disk space the guest paused. > > Hi Kevin, > > While installing a guest into a qcow2 image if the qcow2 image run out > of disk space, the guest will stop work and change state to paused > without messages. > > When we tried to free up disk space in the host and the virsh resume to > work. The guest then got I/O errors but later on QEMU also crashed. > > A guest in paused state is certainly not the best result. > > Probably good way to react are: > - return I/O errors to the guest and the let the guest handle those > (Linux file system code might just crash) > - allow resume only when disk is free again. > > What's your opinion? >