[Qemu-devel] Difference between commit and rebase
I want to remove snapshots and I found two ways: qemu-img commit qemu-img rebase I found they both can choose where to rebase(merge) the images. commit can truncate or not on specific image. rebase won't truncate rebased image. I found they have something similarity and I don't know what situation is suitable for commit or rebase?
Re: [Qemu-devel] Can I mount encrypt qcow2?
I thought 2.9.0 is the latest and check to the wrong commit. Now it supports encryption. My cmd is: > qemu-nbd --object secret,id=sec0,file=passwd.txt,format=raw \ > --image-opts > driver=qcow2,file.filename=demo.qcow2,encrypt.format=luks,encrypt.key-secret=sec0 But it shows error message: > No encryption in image header, but options specified format 'luks' Something wrong? My procedure is below: 1. create a clean demo.qcow2 image(no compression, no encryption) 2. use the cmd above to encrypt the demo.qcow2 image 2017-07-24 20:25 GMT+08:00 Eric Blake : > On 07/23/2017 08:49 PM, 陳培泓 wrote: > > I check to the newest version of qemu. > > You're still top-posting, which makes it really hard to answer your > questions. > > > > > and do the cmds to install followed by the documents in github: > > > >> mkdir build > >> cd build > >> ../configure > >> make > > > > > > and it show nothing errors > > It's the version when I enter qemu-img --help: > > > > and I execute encrypt format(luks) to the qcow2 file: > > > > > > Attaching inline images is a horrible waste of bandwidth, compared to > copying-and-pasting the terminal text directly. Furthermore, your email > is illegible in a plain-text client (like what I prefer to use), and > requires that I switch to html view to even understand what you are asking. > > > always shows the error, how to solve it? > > Transcribing one of your images: > > > pahome@pahome-QW09:~/git/qemu/build$ ./qemu-img --help > > qemu-img version 2.9.0 (v2.9.0-dirty) > > You aren't building the latest version of qemu.git. If you were, you'd > be getting something like this: > > $ ./qemu-img --help | head -n1 > qemu-img version 2.9.50 (v2.9.0-2519-gb52f59694d) > > Before you can complain that something recently added isn't working, you > first have to make sure you are building the right version. > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3266 > Virtualization: qemu.org | libvirt.org > >
[Qemu-devel] why marking qcow2 img as corrupted
I tried take snapshots on a demo.qcow2 10 times. cmd is below: > qemu-img snapshots -c tag_1 demo.qcow2 when I take snapshots 7 times and console shows: > mark image as corrupted and preventing from invalid write and I can't take snapshots anymore then. Can I avoid this situation or remove the limit?
[Qemu-devel] Cluster doesn't truncate after commit to backing file
I have two image A and B, and A is the backing file of B I write data in address addr in A. Then create B and set A as backing file of B. Then I discard the same addr in B. So the entry of addr in l2 table should be 1( also is QCOW2_CLUSTER_ZERO_PLAIN) , right? But the addr cluster in A will fill with zero after I execute `qemu-img commit B` I thought it will truncate or decrease the ref count of the cluster corresponding the addr, but it looks like just fill zero. Is that the default behavior?
[Qemu-devel] qemu-nbd performance
I test nbd performance when I divide image into multiple backing files. The image is 512GB, I divide it into 1, 16, 32, 64, and 128 backing files. Ex: If I divide it into 16 files, each backing file is 512/16=32GB. If I divide it into 64 files, each backing file is 512/64=8GB and so on. *Mount command: qemu-nbd -c /dev/nbd0 image* *Cmd to test:* *Read:* fio -bs=1m -iodepth=16 -rw=read -ioengine=libaio -name=mytest -direct=1 -size=512G -runtime=300 -filename=/dev/nbd0 *Write:* fio -bs=1m -iodepth=16 -rw=read -ioengine=libaio -name=mytest -direct=1 -size=512G -runtime=300 -filename=/dev/nbd0 All images are on the RAID0(3 SSD). Below is the performance: * image numberseq. read(MB/s)seq. write(MB/s)1148060161453363214503664143036128140036* The seq. read performance is very well than write. 1. Does nbd cache the data defaultly and make read so quickly? 2. The write performance isn't so good, Does nbd do something to decrease the performance?
Re: [Qemu-devel] Different type of qcow2_get_cluster_type
> > > Both values correspond to L2 entries with bit 0 set. However, > QCOW2_CLUSTER_ZERO_ALLOC is an entry that has a non-zero value in bits 9-55 > (the cluster has an allocated host location, we guarantee that things read > as zero regardless of whether the host data actually contains zeroes at > that offset, and writes go directly to that offset with no further > allocation required); while QCOW2_CLUSTER_ZERO_PLAIN is an entry with all > zeros in bits 9-55 (we guarantee things read as zero, but writes have to > allocate a new cluster because we have not reserved any space in the host > yet). > If I let one entry called l2_addr of l2 table is 1(also the QCOW2_CLUSTER_ZERO_PLAIN) to make it as discard. After I run qemu-img commit image, and the l2_addr also commit to its backing file. But I saw the same entry l2_addr of l2 table in backing file doesn't show 1, and write corresponding cluster with zero. Is that normal?
Re: [Qemu-devel] qemu-nbd performance
> > All images are on the RAID0(3 SSD). >> Below is the performance: >> > image numberseq. read(MB/s)seq. write(MB/s) 11480 60 16 1453 36 32 1450 36 64 1430 36 128 1400 36 It shows reading better than writing. I confused about why, does qemu did something to delay the write?
Re: [Qemu-devel] qemu-nbd performance
I put image on the 3xSSD RAID0, and the raw performance of block device is read:1500MB/s, write:1400MB/s The bottleneck I thought is the number of backing files. The more images I divide into, lower the read performance Write performance looks like bad originally.
[Qemu-devel] What kind of situation to use internal or external snapshot?
as title, I know there're two snapshots in qemu, but I don't know when to use them well. What I know is internal snapshot will save the info of L1 and L2 table in the end of image but external snapshot won't because external snapshot create new file to save cow data. So when to use internal snapshot or external snapshot? thanks to everyone.
[Qemu-devel] Can I convert backing file to internal snapshot?
I have two qcow2 A & B, and A is backing file of B. Can I convert both A&B to one image and containing data of both? ex: one new image will contain data of A and B. When I check it by qemu-img info, I can see one snapshot in the new image. thanks
Re: [Qemu-devel] What kind of situation to use internal or external snapshot?
> > In general, we've spent more resources developing external snapshots. So > if you want the most support and the fastest response on resolving any > issues that you may encounter, external snapshots are the way to go. > > So internal snapshot is hard to use than external snapshot? Is that because external snapshot is easier to roll back to any snapshot?
[Qemu-devel] Can I only commit from active image to corresponding range of its backing file by qemu cmd?
I split data to 3 chunks and save it in 3 independent backing files like below: img.000 <-- img.001 <-- img.002 img.000 is the backing file of img.001 and 001 is the backing file of 002. img.000 saves the 1st chunk of data and img.001 saves the 2nd chunk of data, and img.002 saves the 3rd chunk of data. Now I have img.003 stores cow data of 1st chunk and img.002 is the backing file of img.003. The backing chain is like this: img.000 <-- img.001 <-- img.002 <-- img.003 So that means the data of img.003 saves the same range with img.000 but different data. I know I can use *`qemu-img commit'* but it only commit the data from img.003 to img.002. If I use *`qemu-img rebase -b img.000 img.003`*, the data of img.001 and img.002 will merge into img.003. What I want is only commit the data in img.003 into img.000 because the data of the two image are the same range(1st chunk) Is there anyway to commit(or merge) data of active image into corresponding backing file? thx
Re: [Qemu-devel] Can I only commit from active image to corresponding range of its backing file by qemu cmd?
Sorry, I need to explain what case I want to do Todo: I want to *backup a block device into qcow2 format image.* I met a problem which is the *file size limit of filesystem* ex: Max is 16TB for any file in ext4, but the block device maybe 32TB or more. I figure out one way is to *divide data of device into 1TB chunk* and save every chunk into qcow2 image cuz I don't change filesystem, and connect with backing chain. *(That's what I said range is different)* Ex: 1st chunk of device will save into image.000 2nd chunk of device will save into image.001 Nth chunk of device will save into image.(N-1) ...etc I can see all block device data when I mount image.(N-1) by qemu-nbd cuz the chunk doesn't overlap and all chunks connect by backing chain. Now I want to do next thing: *Incremental backup* When I modify data of 1st chunk, what I thought is to write new 1st chunk to new image *image.N* and let *imgae.(N-1)* be the backing file of *image.N* . That's cuz I want to store the data before modified to roll back anytime. So now I have two *version of block device(like concept of snapshot)*: One is image.000 to image.(N-1). I can access the data before modify by mount image.(N-1) through qemu-nbd The other one is image.000 to image.N. I can access the data after modify by mount image.N through qemu-nbd(cuz the visible 1st chunk are in the image.N) Consider about the situation: 000 A - - - - - - - - <--- store the 1st chunk of block device 001 - B - - - - - - - 002 - - C - - - - - - (1st state of block device) 003 A' - - - - - - - - <--- store the 1st chunk of block device, but data is different 004 - - - D - - - - - (2nd state of block device) 005 - - - - E - - - - (3rd state of block device) The original problem is If I want to remove the 2nd state(003 and 004) but I need to keep the data of 003 and 004. If I just commit 003, the A' of 003 must be committed into 002 cuz 002 is the backing file of 003. I try to figure out some way to let it only commit from 003 into 000.
Re: [Qemu-devel] What kind of situation to use internal or external snapshot?
In general case, what's difference between internal and external snapshot? I mean in some user situation. Ex: If I want to all snapshots in only one qcow2, I should use internal snapshot. thx
Re: [Qemu-devel] Can I convert backing file to internal snapshot?
Can I convert from internap snapshot to external snapshot? If there's 3 snapshots in one qcow2, can I convert them all to external snapshots?
[Qemu-devel] Different type of qcow2_get_cluster_type
The function qcow2_get_cluster_type() is in /block/qcow2.h It will return the flage based on the entry. There're some flags confused me. What's difference between QCOW2_CLUSTER_ZERO_ALLOC & QCOW2_CLUSTER_ZERO_PLAIN in there?
Re: [Qemu-devel] Can I only commit from active image to corresponding range of its backing file by qemu cmd?
> > > *(That's what I said range is different)* >> Ex: 1st chunk of device will save into image.000 >> 2nd chunk of device will save into image.001 >> Nth chunk of device will save into image.(N-1) >> ...etc >> >> I can see all block device data when I mount image.(N-1) by qemu-nbd cuz >> the chunk doesn't overlap and all chunks connect by backing chain. >> > > How exactly did you create those images? I'm trying to verify the steps > you used to split the image. I know the concept of the split, but without > seeing actual commands used, I don't know that you actually accomplished > the split in the manner desired. (It's okay if a reproduction uses smaller > scales for speed, such as splitting a 32M image across 1M qcow2 files - the > point remains that seeing the actual steps used may offer additional > insights into your usage scenario). > I create those images by my own python scriopt. I research the behaviors when read/write/discard...etc from qemu github. If every image size limit I set is 1TB, script will create next image automatically when refcount of the whole image is all up to 1 and then redirect read/write to the new image. > Or are you trying to ask if it is possible to create such a fragmented > design with current tools? (The answer that we've given you is that no, it > is not easy to do, because no one has needed it so far). There's no way to > tell a running qemu that writes to offsets 0-1M go into one file, while > writes to offsets 1M to 2M go into another - ALL writes go into the > currently active layer, regardless of the offset represented by the write. > Got it, thx. > >> So now I have two *version of block device(like concept of snapshot)*: >> One is image.000 to image.(N-1). I can access the data before modify by >> mount image.(N-1) through qemu-nbd >> The other one is image.000 to image.N. I can access the data after modify >> by mount image.N through qemu-nbd(cuz the visible 1st chunk are in the >> image.N) >> >> Consider about the situation: >> 000 A - - - - - - - - <--- store the 1st chunk of block device >> 001 - B - - - - - - - >> 002 - - C - - - - - - (1st state of block device) >> 003 A' - - - - - - - - <--- store the 1st chunk of block device, but >> data is different >> 004 - - - D - - - - - (2nd state of block device) >> 005 - - - - E - - - - (3rd state of block device) >> >> The original problem is If I want to remove the 2nd state(003 and 004) but >> I need to keep the data of 003 and 004. >> If I just commit 003, the A' of 003 must be committed into 002 cuz 002 is >> the backing file of 003. >> I try to figure out some way to let it only commit from 003 into 000. >> >> > I'm not quite following your diagram. My naive read (probably wrong) is > that you are trying to present a 9M image (scaled M to G or T as > appropriate) to the guest, as represented by the 9 characters, but that the > initial image only populated 3M of the 9 with guest-visible contents > represented by ABC--. So you want to split that into files 000 > containing offsets 0-1M (A), 001 containing offsets 1M-2M > (-B---), and 002 containing offsets 2M-3M (--C--). Then you want > to run the guest, which does some modifications in offsets 0-1M (I'll write > it as "a" instead of "A'", you could also have chosen a different letter > except that your example already uses "D" elsewhere), so the guest now sees > (aBC--), and you want to store that incremental backup in file 003, > containing just (a). But that's where I got confused - my original > assumption was that 003 represented offsets 3M-4M (---X-), but you are > now showing it as representing offsets 0-1M. It's also not clear which > files in your list have which other files as backing files. > > You can view it as snapshots. From 000~002 are the data of 1st snapshot. and 003~004 are the 2nd snapshot. The difference of two snapshot is the 1st chunk(A is in the 1st snapshot and A' is in the 2nd snapshot). So that's why the A' writes in 1st chunk of 003(because 1st of 003 and 000 are the different data). Incremental backup by programming way is just a thought because I try to conquer the file size limit I indeed try rebase and commit command to do this, but still can't do this. Now maybe the case is not normal by everyone. I try to figure out another way or use case to try incremental backup by my own script. > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3266 > Virtualization: qemu.org | libvirt.org >
[Qemu-devel] Any tutorial to read/write in qcow2 format by programming way?
As titled I learn some info about qcow2 and tried to write some data and make it qualified for qcow2 format. I do it and mount through qemu-nbd successfully. But I don't know how taking snapshot and backing file works in programming way. Can someone tell me some tutorial to know or code snippets to learn? thx
Re: [Qemu-devel] Any tutorial to read/write in qcow2 format by programming way?
I have some questions about qcow2 If I have 2 img A & B, and A is backing file of B. Is the format(such as L1, L2, ref block...etc) different from A and B? > No real tutorial other than reading the code and the file format > specification (it's open source, after all). See: > block/qcow2* > docs/interop/qcow2.txt > > Other potential resources to study: > > https://github.com/jnsnow/qcheck.git > > implements a rudimentary qcow2 image checker, although it still does not > handle incremental snapshots. Then again, if you want to learn the qcow2 > image format, enhancing that tool would be a great asset in your quest. > >
[Qemu-devel] Can I create img more thant 16TB?
There's file size maximum in ext4 and it's 16TB Can I create qcow2 ex:32TB and write more than 16TB? thx
[Qemu-devel] How to discard one range which overlap with backing file and its children img?
I have image A & B, and A is backing file of B. After I mount A to /dev/nbd0 and I write from position 0~999 in nbd0. Then create B and set A as backing file of B. I mount B on /dev/nbd1 and I can saw the data from pos:0~999 because A is B's backing file. That's reasonable. But I want to discard range 0~500 in B. I expect there's no data in 0~500 after discard and re-mount B next time. But the data is still in A. How can I discard range 0~500?
[Qemu-devel] How do you do when write more than 16TB data to qcow2 on ext4?
We all know there's a file size limit 16TB in ext4 and other fs has their limit,too. If I create an qcow2 20TB on ext4 and write to it more than 16TB. Data more than 16TB can't be written to qcow2. So, is there any better ways to solve this situation? What I thought is to create new qcow2 called qcow2-new and setup the backing file be the previous qcow2.
Re: [Qemu-devel] How do you do when write more than 16TB data to qcow2 on ext4?
Really? How to mount a blk device to /dev/nbdN? I always find tips to mount from file-like image to /dev/nbdN 2018-08-16 19:46 GMT+08:00 Eric Blake : > On 08/16/2018 03:22 AM, Daniel P. Berrangé wrote: > >> On Thu, Aug 16, 2018 at 09:35:52AM +0800, lampahome wrote: >> >>> We all know there's a file size limit 16TB in ext4 and other fs has their >>> limit,too. >>> >>> If I create an qcow2 20TB on ext4 and write to it more than 16TB. Data >>> more >>> than 16TB can't be written to qcow2. >>> >>> So, is there any better ways to solve this situation? >>> >> >> I'd really just recommend using a different filesystem, in particular XFS >> has massively higher file size limit - tested to 500 TB in RHEL-7, with a >> theoretical max size of 8 EB. It is a very mature filesystem & the default >> in RHEL-7. >> > > Or target raw block devices instead of using a filesystem. LVM works great. > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3266 > Virtualization: qemu.org | libvirt.org >
[Qemu-devel] What does VM SIZE means when entering qemu-img info xx.qcow2
I have an qcow2 image and I mount it to /dev/nbd then write somethin. Then I take internal snapshot in the qcow2. I enter the command qemu-img info qcow2 It shows: image: qcow2 file format: qcow2 virtual size: 30G disk size:4M x Snapshot list: ID, TAG, VM SIZE, DATE, VM CLOCK 1, snap1, 0, -xx-xx, 00:00:00 The field of "VM SIZE" is zero in my host machine. What does it mean and why is it an zero?
