From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48868)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1VC4Qx-0000Yn-V8
	for qemu-devel@nongnu.org; Wed, 21 Aug 2013 05:10:40 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1VC4Qp-0001ea-4U
	for qemu-devel@nongnu.org; Wed, 21 Aug 2013 05:10:31 -0400
Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:48794)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1VC4KW-0007bH-N8
	for qemu-devel@nongnu.org; Wed, 21 Aug 2013 05:03:52 -0400
Received: by mail-wi0-f170.google.com with SMTP id hi8so447121wib.1
	for <qemu-devel@nongnu.org>; Wed, 21 Aug 2013 02:03:51 -0700 (PDT)
Date: Wed, 21 Aug 2013 11:03:49 +0200
From: Stefan Hajnoczi <stefanha@gmail.com>
Message-ID: <20130821090349.GD10379@stefanha-thinkpad.redhat.com>
References: <52062D34.1050804@linux.vnet.ibm.com>
	<520E2798.7030607@linux.vnet.ibm.com>
	<20130820144348.GC5536@stefanha-thinkpad.redhat.com>
	<20130820145740.GA5579@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130820145740.GA5579@redhat.com>
Subject: Re: [Qemu-devel] Fwd: [libvirt] virDomainAttachDevice error during
 disk hotplug
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Deepak C Shetty <deepakcs@linux.vnet.ibm.com>, qemu-devel@nongnu.org

On Tue, Aug 20, 2013 at 03:57:40PM +0100, Daniel P. Berrange wrote:
> On Tue, Aug 20, 2013 at 04:43:48PM +0200, Stefan Hajnoczi wrote:
> > On Fri, Aug 16, 2013 at 06:52:32PM +0530, Deepak C Shetty wrote:
> > > 2) qemu-img info /var/run/vdsm/3333017d-1278-4bfb-8129-62bded257399
> > > image: /var/run/vdsm/3333017d-1278-4bfb-8129-62bded257399
> > > file format: qcow2
> > > virtual size: 3.8G (4096000000 bytes)
> > > disk size: 196K
> > > cluster_size: 65536
> > > backing file:
> > > /rhev/data-center/000065de-04b8-42e2-986c-2de664708be7/11112d24-4cda-4200-8f6d-a1d8362c70fd/images/22224c45-6504-4ea1-bd24-12340017dd32/3333017d-1278-4bfb-8129-62bded257399
> > > backing file format: qcow2
> > 
> > Good, QEMU can parse and read the file.
> > 
> > > 3) ls -l
> > > /rhev/data-center/000065de-04b8-42e2-986c-2de664708be7/11112d24-4cda-4200-8f6d-a1d8362c70fd/images/22224c45-6504-4ea1-bd24-12340017dd32/3333017d-1278-4bfb-8129-62bded257399
> > > -r--r-----. 1 vdsm kvm 197120 Aug 10 11:59
> > > /rhev/data-center/000065de-04b8-42e2-986c-2de664708be7/11112d24-4cda-4200-8f6d-a1d8362c70fd/images/22224c45-6504-4ea1-bd24-12340017dd32/3333017d-1278-4bfb-8129-62bded257399
> > 
> > Read-only?
> > 
> > > 4) libvirtd.log snippets:
> > > 
> > > 2013-08-10 11:19:41.766+0000: 1103: debug : virDomainAttachDevice:9820 :
> > > dom=0x7f92f4003f20, (VM: name=dpk_BR_vm,
> > > uuid=9999017d-1278-4bfb-8129-62bded257399), xml=<disk device="disk"
> > > snapshot="no" type="file">
> > >         <source file="/var/run/vdsm/3333017d-1278-4bfb-8129-62bded257399"/>
> > >         <target bus="virtio" dev="vdb"/>
> > > <serial>22224c45-6504-4ea1-bd24-12340017dd32</serial>
> > >         <driver cache="none" error_policy="stop" io="threads"
> > > name="qemu" type="qcow2"/>
> > > </disk>
> > 
> > I see no read-only option.
> > 
> > Does it work if you make the file read-write instead?
> 
> FYI this was solved in libvir-list.
> 
> The image file was on tmpfs, which does not support cache=none.
> 
> We hit this so often it would be a huge help if QEMU reported a
> clearer error message then "Invalid Argument" when trying cache=none
> on tmpfs.

The kernel only tells us EINVAL but if this is a common issue we could
add a tmpfs check and print advice (note that it's only advice because
future kernel versions might lift this limitation of tmpfs).

Stefan