search for: qcow2s

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

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

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"

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

Hi All I was reading through this: http://kashyapc.com/2011/12/02/little-more-disk-io-perf-improvement-with-fallocateing-a-qcow2-disk/ I was basically searching for pointers on improving disk I/O. I wanted to know the purpose of preallocation=full & preallocation=metadata , What is the difference between them ? and which one would yield a better disk I/O speed ? Appreciate your

Hello list, upon upgrading from libvirt v5.9.0 -> v5.10.0, libvirt started calling qemu differently causing the VM operating system to not be found. I'm wondering whether I'm chasing a bug, or have to otherwise fix my domain config (created by virt-manager). To start with, I have a Windows 7 domain based on the following images: windows7-base.qcow2: QEMU QCOW2 Image (v3),

Hi all. I have a few questions regarding the qcow2 format. 1/ Allocated size vs. file size When creating a VM, I indicated a size of 10 G. $ls -lsh 7,7G -rw------- 1 libvirt-qemu libvirt-qemu 11G oct. 14 10:04 prod.qcow2 The allocated size is lesser than max size. Alright. I think I more or less grab the difference between allocated size and file size, but I'm not sure I get the point

Hey, guys I've been working on whether libvirt supports encrypted snapshots,Here are my versions of libvirt and qemu [root@xx ~]# libvirtd -V libvirtd (libvirt) 4.5.0 [root@xx ~]# qemu-img -V qemu-img version 2.12.0 (qemu-kvm-ev-2.12.0-33.1.el7_7.4) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers 1. assign $MYSECRET to libvirt secret using the secret-define and

On Wed, Jun 22, 2016 at 05:56:09PM -0500, libvirt_users@skagitattic.com wrote: > > Delete what you've done and start from the beginning. Describe > > exactly how you created the guest. Use 'qemu-img info' to show the > > format of the input file. Show precisely the virt-sparsify command > > you are running. And use 'qemu-img info' on the output file

> Delete what you've done and start from the beginning. Describe > exactly how you created the guest. Use 'qemu-img info' to show the > format of the input file. Show precisely the virt-sparsify command > you are running. And use 'qemu-img info' on the output file too. Okay, here goes. Start off with an install root@testingbox:~ # virt-install --name

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

On Wed, Nov 21, 2018 at 09:25:05AM +0000, Richard W.M. Jones wrote: > nbdkit: file.2: error: invalid request: offset and count are out of range: offset=196608 count=512 Actually what happens even more precisely is that the underlying file is not a multiple of 512 bytes (196624 ≡ 16 mod 512). qemu-img (the client) issues a request for the final "sector" of the file which goes beyond

On Mon, Dec 16, 2019 at 12:49:40 +0100, Jens John wrote: > Hello list, Hi Jens, > > upon upgrading from libvirt v5.9.0 -> v5.10.0, libvirt started calling > qemu differently causing the VM operating system to not be found. I'm > wondering whether I'm chasing a bug, or have to otherwise fix my domain > config (created by virt-manager). Yes, this change was done by

Il 30-01-2018 13:17 Gionatan Danti ha scritto: > 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

Hi, Recently We've upgraded some KVM hosts from Fedora 29 to Fedora 30 and now experience broken VM configurations on filesystem after virsh blockcommit. Commands "virsh dumpxml ..." and "virsh dumpxml --inactive ..." is showing diffrent configuration than the one on filesystem. In case of restart libvirtd or system reboot, there are broken VM xml configurations on

QCOW2 disk image gets corrupted when you try to install Service Pack 1 AFTER installing GPLPV drivers. This means, without the pv drivers, everything works fine. I tested both RAW and QCOW2 without GPLPV drivers and the installation has completed without any error, and the image (at least qcow2) has no errors too. How to reproduce: - Install Windows 7 32-bit guest - Check the image with

Hello Rich, Thanks for the reply and information. > What is file.img? Its simply a file I made while testing sparse files "truncate -s 512M file.img". > 'du --apparent-size' and 'ls -l' are the same thing, so it's not > really surprising that you see the same numbers here. Indeed, I expected those to be the same, just figured I would show them both for

On 01/08/2015 12:44 PM, Gary R Hook wrote: > I've learned how to use the blockcopy command to create a local copy in > a simple disk file: > > virsh dumpxml my_domain > my_domain.xml > virsh undefine my_domain > virsh blockcopy --domain my_domain vda $PWD/dsk.copy.qcow2 --wait > --verbose --finish > virsh define my_domain.xml > > and the resulting copy in

On 11/21/18 4:39 AM, Richard W.M. Jones wrote: > On Wed, Nov 21, 2018 at 09:25:05AM +0000, Richard W.M. Jones wrote: >> nbdkit: file.2: error: invalid request: offset and count are out of range: offset=196608 count=512 > > Actually what happens even more precisely is that the underlying file > is not a multiple of 512 bytes (196624 ≡ 16 mod 512). > > qemu-img (the client)