similar to: after snapshot-delete, the qcow2 image file size doesn't decrease

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 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

How do I find what "eafb8799-4e7a-4264-9213-26997c5a4693" is? https://docs.gluster.org/en/v3/Troubleshooting/gfid-to-path/ On May 21, 2018 3:22:01 PM PDT, Thing <thing.thing at gmail.com> wrote: >Hi, > >I seem to have a split brain issue, but I cannot figure out where this >is >and what it is, can someone help me pls, I cant find what to fix here. >

I tried this already. 8><--- [root at glusterp2 fb]# find /bricks/brick1/gv0 -samefile /bricks/brick1/gv0/.glusterfs/ea/fb/eafb8799-4e7a-4264-9213-26997c5a4693 /bricks/brick1/gv0/.glusterfs/ea/fb/eafb8799-4e7a-4264-9213-26997c5a4693 [root at glusterp2 fb]# 8><--- gluster 4 Centos 7.4 8><--- df -h [root at glusterp2 fb]# df -h Filesystem

Hi, I seem to have a split brain issue, but I cannot figure out where this is and what it is, can someone help me pls, I cant find what to fix here. ========== root at salt-001:~# salt gluster* cmd.run 'df -h' glusterp2.graywitch.co.nz: Filesystem Size Used Avail Use% Mounted on /dev/mapper/centos-root

I tried looking for a file of the same size and the gfid doesnt show up, 8><--- [root at glusterp2 fb]# pwd /bricks/brick1/gv0/.glusterfs/ea/fb [root at glusterp2 fb]# ls -al total 3130892 drwx------. 2 root root 64 May 22 13:01 . drwx------. 4 root root 24 May 8 14:27 .. -rw-------. 1 root root 3294887936 May 4 11:07 eafb8799-4e7a-4264-9213-26997c5a4693 -rw-r--r--. 1 root

Hi, Which version of gluster you are using? You can find which file is that using the following command find <brickpath> -samefile <brickpath/.glusterfs/<first two bits of gfid>/<next 2 bits of gfid>/<full gfid> Please provide the getfatr output of the file which is in split brain. The steps to recover from split-brain can be found here,

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

For many months now we have been trying to create a file-backed qcow image with the qcow-create code. Each time we try to back a file with a qcow, it screams: *** buffer overflow detected ***: qcow-create terminated Below is the output from two different attempts and information about qcow-create. Any ideas/thoughts/help you can offer? Thank you for your help! -Eric [root@trogdor ~]#

Hi, On a debian 9 client, ======== root at kvm01:/var/lib/libvirt# dpkg -l glusterfs-client 8><--- ii glusterfs-client 3.8.8-1 amd64 clustered file-system (client package) root at kvm01:/var/lib/libvirt# ======= I am trying to to do a mount to a Centos 7 gluster setup, ======= [root at glustep1 libvirt]# rpm -q glusterfs glusterfs-4.0.2-1.el7.x86_64

Hi, Trying to understand the current state of affairs with QCOW support in Xen with the blktap driver. It''s been made clear that a deviation from QEMU''s implementation of QCOW has occurred and that the QCOW files used in Xen must be created with the associated Xen tools only (e.g. qcow-create) and that images between QEMU and Xen are not interchangeable. My first question is

Hi! Changeset 17913 breaks build on *BSD: block-qcow.c:36:20: error: gcrypt.h: No such file or directory cc1: warnings being treated as errors block-qcow.c: In function ''gen_cksum'': block-qcow.c:160: warning: implicit declaration of function ''gcry_md_hash_buffer'' block-qcow.c:160: error: ''GCRY_MD_MD5'' undeclared (first use in this function)

tags 490409 + patch thanks Hi, The following is the diff for my xen-3 3.2.1-2.1 NMU. It incorporates three patches from upstream and aims to fix CVE-2008-2004 aka #490409. It is not yet tested much, I would appreciate if interested parties could give it a try. I'll upload in due course. Kind regards T. diff -u xen-3-3.2.1/debian/control.md5sum xen-3-3.2.1/debian/control.md5sum ---

F12, libvirt 0.7.1-15, qemu 0.11.0-12, 32 bit I recently discovered that libvirt is stealing ownership of my disk images. How can I make it stop? I have a disk image in my home directory, owned by matt. When I create a domain that uses the disk it gets chowned to qemu.qemu. When the domain terminates it is owned by root.root. I've lost access to the file. It has been suggested that the

Dear,Beg for your help. I am really puzzled with this problem.HVM domain can not boot up with Qcow incremental image(using command: qcow-create size incremental_file original_Qcow_img_file), but it can boot up with the original Qcow disk image file. When using Qcow incremental image, the guest qemu window would disappear before loading grub, and `xm list` can not find this guest domain.The VM

Hi John, Thank you. For my system shows like below. df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 909G 576G 287G 67% / tmpfs 3.9G 0 3.9G 0% /dev/shm /dev/sda1 3.9G 160M 3.5G 5% /boot /dev/sdb1 916G 382G 488G 44% /bkhdd First hard disk /dev/sda Second hard disk /dev/sdb The problem is in first hard disk show above size but my email

Hi Martin, in the meantime, I've found a solution which I consider at least acceptable: 1. create zfs snapshot of domain disk (/dev/zstore/test-volume) 2. save original XML domain definition 3. create snapshot in libvirt like this: virsh snapshot-create --xmlfile snap.xml --disk-only --no-metadata test-domain snap.xml: <domainsnapshot> <disks> <disk

Hi,guys, During a HVM''s running which take a qcow format image file as its own virtual disk, the qcow image file will be always read.In the situation that its qcow format image is based on a raw format image, if nesethe backingfile ,just that raw format image file,would be read .my purpose is to cache the data that is read from the backingfile when the hvm is running . Now what I concern

Hello, This is a second post, with a trial which is different from the first one , in order to solve my blcok-attach problem. I tried the following two actions, according to the blktap readme: qcow-create 1000 qcowFile.img Creating file size 1048576000 Created cksum: 1813725440 then xm block-attach 0 tap:qcow:qcowFile.img /dev/xvda1 w 0 I see in the /var/log/xen/xend.log: [2007-03-13

I have a qcow file It shows correct size on one server Fdisk -l w.qcow 70 GB On the other server Fdisk w.qcow 0 MB stupid