On Wed, Aug 21, 2013 at 11:03:49AM +0200, Stefan Hajnoczi wrote: > 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).
Rather than checking for tmpfs, you could simply re-try the open() call without O_DIRECT. If that passes, then you can safely issue an error message saying that the filesystem doesn't support O_DIRECT. This will make it robust to other future filesystems which may also not do O_DIRECT Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|