qemu-img

由 datahunter 在四, 14/09/2023 - 21:21 發表

Supported options:
size             Virtual disk size
adapter_type     Virtual adapter type, can be one of ide (default), lsilogic, buslogic or legacyESX
backing_file     File name of a base image
compat6          VMDK version 6 image
subformat        VMDK flat extent format, can be one of {monolithicSparse (default) | ...
zeroed_grain     Enable efficient zero writes using the zeroed-grain GTE feature

Get smaller image

convert 過程 the empty sectors are detected and suppressed from the destination image.

# 必須指定 Output format(-O qcow2), 否則 new.qcow2 的 type 是 RAW, 而不是 qcow2

qemu-img convert -p -O qcow2 u22.qcow2 new.qcow2

ls -lh *.qcow2

resize filename [+|-]size

qemu-img resize data.vdi +5G # 只有 qcow2 才 support resize

kvm-img: This image format does not support resize

qemu-img resize vda.qcow2 +5g # 有 snapshoot 不能 resize

qemu-img: Can't resize an image which has snapshots

qemu-img resize data.qcow2 +5g #- 另有單位 'M' (megabyte, 1024k)

Image resized.

virtual size 與 disk size

# mydisk.qcow2 由 10G resize 成 18G 後

qemu-img info mydisk.qcow2

image: mydisk.qcow2
file format: qcow2
virtual size: 18G (19327352832 bytes)
disk size: 10G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: true
    refcount bits: 16
    corrupt: false

fallocate -l 18G mydisk.qcow2

Shrinking

Shrinking an image will delete all data beyond the shrunken image's end.

qemu-img resize vdb.qcow2 --shrink 5g

進階 CMD

snapshot

Snapshot

Syntax

snapshot [-l | -a snapshot | -c snapshot | -d snapshot ] filename (list, apply(revert disk), create or delete)

Create snapshot

qemu-img snapshot -c win7.qcow2

qemu-img snapshot -c CleanOS lxc-r8.qcow2 # 將 TAG 設定成 CleanOS

List snapshot

qemu-img snapshot -l win7.qcow2

Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         1416882145                0 2014-11-25 10:22:26   00:00:00.000
2         1455676457                0 2016-02-17 10:34:17   00:00:00.000
3         1470803281                0 2016-08-10 12:28:01   00:00:00.000
4         1514889149                0 2018-01-02 18:32:30   00:00:00.000
5         1519353171                0 2018-02-23 10:32:51   00:00:00.000
6         1519354898                0 2018-02-23 11:01:38   00:00:00.000

Delete snapshot

qemu-img snapshot -d 1416882145 win7.qcow2

* Delete 完 snapshot 後 image 不會變細

Restore snaphost

qemu-img snapshot win7.qcow2 -a 1519354898

Convert snapshot to image

list snapshot in image

qemu-img snapshot -l win7.qcow2

Clone snapshot

# -l snapshot_param

# 必須加 "-O" 否則會是 raw format

qemu-img convert -O qcow2 -p -l 1514889149 win7.qcow2 win7-ii.qcow2

Checking

qemu-img info win7-ii.qcow2

image: win7-ii.qcow2
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 7.9G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Base Image

convert
create
commit
rebase

建立 Base (Directory -> qcow2)

qemu-img convert -O qcow2 /path/to/directory /lxc/vps/rootdev.qcow2

mount live image

qemu-nbd -c /dev/nbd0 -n --aio=native /lxc/vps/rootdev-live.qcow2

Base Image 的 backing_file

cd /lxc/vps

qemu-img create -f qcow2 -o backing_file=rootdev.qcow2 rootdev-live.qcow2

# backing_file: image will record only the differences from backing_file

Remark:

qemu-img info rootdev-live.qcow2

image: rootdev-live.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 196K
cluster_size: 65536
backing file: rootdev.qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Commit (把所有變更寫回 base image)

qemu-img commit rootdev-live.qcow2

Image committed.

# 記得順手清了它

rm rootdev-live.qcow2

Image 的 Cluster Size

A qcow2 file is organized in units of constant size called clusters. (Defaults: 64KiB)

The virtual disk seen by the guest is also divided into guest clusters size.

Qcow2 Cluster Size: 512bytes ~ 2Mbytes

Check cluster size

qemu-img info myvm.qcow2

image: myvm.qcow2
file format: qcow2
virtual size: 18G (19327352832 bytes)
disk size: 18G
cluster_size: 65536

L1 and L2 table

In order to map the virtual disk as seen by the guest to the qcow2 image in the host,

the qcow2 image contains a set of tables organized in a two-level structure.

These are called the L1 and L2 tables.

L1 table

single L1 table per disk image

always kept in memory

L2 table

There can be many L2 tables (depending on how much space has been allocated in the image)

QEMU needs to read its corresponding L2 table to find out where that data is located (each I/O operation)

QEMU keeps a cache of L2 tables in memory

L2 table cache

QEMU has a default L2 table cache of 1Mb

disk_size = l2_cache_size * cluster_size / 8

With the default values for cluster_size (64KB), l2_cache_size (1Mb)

disk_size = 1Mb * 64/8 = 8G

Qemu Options:

# Both caches must have a size that is a multiple of the cluster size

l2-cache-size: maximum size of the L2 table cache
refcount-cache-size: maximum size of the refcount block cache
cache-size: l2-cache-size + refcount-cache-size

i.e.

-drive file=hd.qcow2,l2-cache-size=2097152
-drive file=hd.qcow2,refcount-cache-size=524288
-drive file=hd.qcow2,cache-size=2621440

If only "cache-size" is specified then QEMU will assign as much memory as possible to the L2 cache before increasing the refcount cache size.

refcount blocks

The qcow2 format mantains a reference count for each cluster.

(for cluster allocation and internal snapshots)

The data is stored in a two-level structure

The second level structures are called refcount blocks (one cluster in size)

cache-clean-interval(Default: 600)

# (當 snapshots 後, 由於是 COW, 所以舊 blocks 不會再存取)

# removes all unused cache entries every 15 minutes:

-drive file=hd.qcow2,cache-clean-interval=900

Lazy Refcounts

Lazy refcounts is a performance optimization for qcow2 that

postpones refcount metadata updates and instead marks the image dirty.

In the case of crash or power failure the image will be left in a dirty state

and repaired next time it is opened.

(in other words we need an fsck-like scan on startup)

Reducing metadata I/O is important for cache=writethrough and cache=directsync

because these modes guarantee that data is on disk after each write

(hence we cannot take advantage of caching updates in RAM).

Refcount metadata is not needed for guest->file block address translation

and therefore does not need to be on-disk at the time of write completion

this is the motivation behind the lazy refcount optimization.

The key insight is that refcounts are not required to access data in the image.

This means that we can postpone refcount updates without violating the data

integrity guarantee that cache=writethrough and cache=directsync give.

Allocating writes are expensive because they involve updating L2 tables and refcount blocks.

In addition they can also cause L2 table allocation and refcount block allocation

but these remain unaffected by this optimization.

The lazy refcount optimization must be enabled at image creation time:

[Create Image]

qemu-img create -f qcow2 -o compat=1.1,lazy_refcounts=on new.qcow2 10G

qemu-img convert -f qcow2 -O qcow2 -o compat=1.1,lazy_refcounts=on from.qcow2 to.qcow2

[Run VM]

qemu-system-x86_64 -drive if=virtio,file=a.qcow2,cache=writethrough