Bug#726629: qemu-utils: please support qemu-img option preallocation=full for qcow2
Michael Tokarev dixit:
some other distros have preallocation=full option for qemu-img
Which other distros?
lsb_release -a says:
LSB Version:
:base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description:CentOS release 6.4 (Final)
Release:6.4
Codename: Final
qcow2 format, somehow Debian (even sid) doesn’t.
Please add it, because this is needed in order to not overcommit
the available VM backing store space when one is unable to directly
use LVs for storage.
I don't plan to apply feature patches to upstream qemu.
I wasn’t aware that this feature is not upstream. Do you
think upstream would be willing to add it?
Thanks,
//mirabilos
--
Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726629: qemu-utils: please support qemu-img option preallocation=full for qcow2
19.10.2013 00:01, Thorsten Glaser wrote: Michael Tokarev dixit: some other distros have preallocation=full option for qemu-img Which other distros? lsb_release -a says: LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: CentOS Description:CentOS release 6.4 (Final) Release:6.4 Codename: Final That's redhat, who is famous for their patching of stuff, so that their software becomes incompatible with anything at all. qcow2 format, somehow Debian (even sid) doesn’t. Please add it, because this is needed in order to not overcommit the available VM backing store space when one is unable to directly use LVs for storage. I don't plan to apply feature patches to upstream qemu. I wasn’t aware that this feature is not upstream. Do you think upstream would be willing to add it? I don't think this makes any sense. If you want fully-pre-allocated images, just use raw, there's no need to use qcow at all. You'll get nothing but overhead (in both of image size and processing time), and becomes more difficult for proper alignment (in case of disks with larger sector sizes). Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726629: qemu-utils: please support qemu-img option preallocation=full for qcow2
Michael Tokarev dixit: I don't think this makes any sense. If you want fully-pre-allocated images, just use raw, there's no need to use qcow at all. You'll get I'd actually prefer using an LVM LV, but I can’t always do what I want. (In my case, the other admins argue with “qcow2 can do (multiple) snap‐ shots of a VM”. Not that I ever made a snapshot, at all.) nothing but overhead (in both of image size and processing time), and becomes more difficult for proper alignment (in case of disks with larger sector sizes). Is this really true even for fully preallocated qcow2 images without compression enabled? If so, I think I’ve got enough reason to at least use a raw image on the NAS-via-NFS setup. Thanks, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726629: qemu-utils: please support qemu-img option preallocation=full for qcow2
Package: qemu-utils Version: 1.6.0+dfsg-2 Severity: wishlist Hi, some other distros have preallocation=full option for qemu-img qcow2 format, somehow Debian (even sid) doesn’t. Please add it, because this is needed in order to not overcommit the available VM backing store space when one is unable to directly use LVs for storage. Thanks! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages qemu-utils depends on: ii libaio1 0.3.109-4 ii libc62.17-93 ii libcurl3-gnutls 7.33.0-1 ii libglib2.0-0 2.36.4-1 ii libiscsi11.4.0-3 ii libssh2-11.4.3-1 ii libuuid1 2.20.1-5.5 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages qemu-utils recommends: ii sharutils 1:4.13.5-1 Versions of packages qemu-utils suggests: ii debootstrap 1.0.53 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726629: qemu-utils: please support qemu-img option preallocation=full for qcow2
Control: tag -1 + wontfix 17.10.2013 16:31, Thorsten Glaser wrote: Package: qemu-utils Version: 1.6.0+dfsg-2 Severity: wishlist Hi, some other distros have preallocation=full option for qemu-img Which other distros? qcow2 format, somehow Debian (even sid) doesn’t. Please add it, because this is needed in order to not overcommit the available VM backing store space when one is unable to directly use LVs for storage. I don't plan to apply feature patches to upstream qemu. Only fixes please. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
