similar to: preallocation=full Vs preallocation=metadata

On Tue, Jun 02, 2015 at 09:14:03AM +0530, Jatin Davey wrote: > Hi All > > I was reading through this: > > http://kashyapc.com/2011/12/02/little-more-disk-io-perf-improvement-with-fallocateing-a-qcow2-disk/ In my testing, the above method gives near-raw performance as it preallocated all the space ahead of time. The above test can now be done in a single command -- see option (3)

Hi, Thanks Kashyap for your answer. I am trying to give more data: virt-install invokation: # virt-install --name eff1 --disk /home/kvmimages/eff1.img --cdrom /home/kvmimages/Fedora-20-x86_64-DVD.iso --memory 4096 WARNING CDROM media does not print to the text console by default, so you likely will not see text install output. You might want to use --location. Début d'installation...

Hi all, experimenting with vol-create-as, I think it should autodetect some data - filesize and backing file format, specifically. However, the current implementation require us to specify both filesize and backing file format. Considering that qemu-img already autodetects these data, there are any reason for the lack of autodetect by libvirt? Should I open a bugzilla issue? Below you can

2017-11-15 23:55 GMT+01:00 Max Reitz <mreitz@redhat.com>: > https://xanclic.moe/convert-xva.rb -- does this work? > (It seems to works on the two example images I found...) > > An example is in the code, you use it like this: > > $ ./convert-xva.rb ~/Downloads/stats-appliance-2.36.020502.xva Ref:73 It doesn't work on huge images: # time convert-xva.rb

Hello, I am curious why when using virt-sparsify the apparent-size of the file gets reduced to the actual file size? Is there a way to get the apparent-size left as the full size? In the man page for virt-sparsify it has a section on "IMPORTANT NOTE ABOUT SPARSE OUTPUT IMAGES" and its output seems to indicate what I would expect where "ls -lh" shows the full apparent size

Hello, I am curious why when using virt-sparsify the apparent-size of the file gets reduced to the actual file size? Is there a way to get the apparent-size left as the full size? In the man page for virt-sparsify it has a section on "IMPORTANT NOTE ABOUT SPARSE OUTPUT IMAGES" and its output seems to indicate what I would expect where "ls -lh" shows the full apparent size

Thanks for your interest. Here are the dir/files permissions for the kvmimages dir: # ls -ld /home /home/kvmimages /home/kvmimages/* drwxr-xr-x. 4 root root 4096 14 juin 23:05 /home drwxrwxrwx 2 root root 4096 15 juin 09:19 /home/kvmimages -rw-rw-rwx 1 root root 12884901888 14 juin 23:07 /home/kvmimages/eff1.img -rw-rw-rwx 1 root root 12884901888 14 juin 23:11

I have not found support in libvirt (nor virsh) for doing the equivalent of "qemu-img rebase ....". The use case: You have copied a qcow2 stack and the new files have different names or reside in a different directory. Therefore you need to change the backing file. Is there a way to do this? Is this a planned addition to libvirt? Harald -------------- next part

This worked wonderfully!  What are the odds of getting this upstream in the near future?  I'd rather not build from source in production. # ./run guestfish --format=raw --ro -a rbd://[fd00::cefc:1]:6789/images/CentOS-7-x86_64-GenericCloud-1901 libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: set_tmpdir "/root/libguestfs/tmp" libguestfs:

Thank you, Rich, This was the issue indeed. export LIBGUESTFS_BACKEND=direct fixed it. The next step I tried was to integrate libguestfs in collectd virt plugin to collect this data automatically. In this case I'm having an unknown error in add_libvirt_dom() (same with add_domain) when it's invoking qemu-img to create overlay image. There is no difference between manual and service

On Thu, Jun 23, 2016 at 10:57:43AM -0500, libvirt_users@skagitattic.com wrote: > Thanks for all the information, I think my last remaining question is > why the image created with virt-install shows the full apparent size > and the image from virt-sparsify does not? (The image testimage1.qcow2 > created with default options). I don't really know what you mean by "full

On Wed, Jun 22, 2016 at 12:40:40AM -0500, libvirt_users@skagitattic.com wrote: > So you are saying when I do the virt-sparsify its converting the image > from raw to [qcow2]? No. virt-sparsify will use the same input and output formats, unless you use the --convert option. > I studied the man page for virt-sparsify and tried again with > the flag "--format raw"

I believe the bug lies in libguestfs. Taking out the commands being sent to QEMU and using qemu-img info I can recreate the error: # qemu-img info "rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00::cefc:1]\:6789:auth_supported=none" qemu-img: Could not open 'rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00::cefc:1]\:6789:auth_supported=none': invalid

Hi All, When I tried to create preallocated image with gluster , I am unable to create one The image gets created but not preallocated. [root@ ]# qemu-img create -f qcow2 -o preallocation=full gluster://host1.lab.eng.blr.redhat.com/rep3vol/vm3.img 3G Formatting 'gluster://dhcp37-61.lab.eng.blr.redhat.com/rep3vol/newvm3.img', fmt=qcow2 size=3221225472 encryption=off cluster_size=65536

A lot of code runs 'qemu-img create' or 'truncate' to create blank disk images. In the past I resisted adding an API to do this, since it essentially duplicates what you can already do using other tools (ie. qemu-img). However this does simplify calling code quite a lot since qemu-img is somewhat error-prone to use (eg: don't try to create a disk called "foo:bar")

I am unable to convert a vm using virt-v2v. From the trace and debug logs I am unable to understand the cause of the problem. I assume it is a permission or configuration issue but I don't know where to start looking. The following command was issued: LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1 virt-v2v -ic qemu+ssh://xxx at 192.168.xxx.xxx/system -o rhev -os 192.168.xxx.xxx:/mnt/exports -of

Hi all, on a fully patched CentOS 7.4 x86-64, I see the following behavior: - when creating a new volumes using vol-create-as, the resulting file is a qcow2 version 2 (compat=0.10) file. Example: [root@gdanti-lenovo vmimages]# virsh vol-create-as default zzz.qcow2 8589934592 --format=qcow2 --backing-vol /mnt/vmimages/centos6.img Vol zzz.qcow2 created [root@gdanti-lenovo vmimages]# file

For raw, this allows "off" as a synonym for "sparse" (to make it consistent with qcow2). For qcow2, this allows "sparse" as a synonym for "off". It also adds qcow2 "full" preallocation, which is actually mapped to the qemu option "falloc" (see arguments about this on the qemu-devel mailing list, which we lost). This also updates the

Sorry for posting bad debug info. Here are the right one with the chardev error only: # virt-install --name f20vm --disk /home/kvmimages/f20vm --cdrom /home/kvmimages/Fedora-20-x86_64-DVD.iso --memory 2048 -d [dim., 15 juin 2014 10:56:25 virt-install 9795] DEBUG (cli:187) Launched with command line: /usr/share/virt-manager/virt-install --name f20vm --disk /home/kvmimages/f20vm --cdrom

Hi, What's the difference between QEMU snapshot and libvirt snapshot? # qemu-img create -f qcow2 disk.img 512 Formatting 'disk.img', fmt=qcow2 size=512 encryption=off cluster_size=65536 lazy_refcounts=off # qemu-img info disk.img image: disk.img file format: qcow2 virtual size: 512 (512 bytes) disk size: 136K cluster_size: 65536 Format specific information: compat: 1.1 lazy