RAW
raw是默認的格式，格式簡單，容易轉換為其他的格式。需要文件系統的支持才能支持sparse file
創建image
# qemu-img create -f raw flat.img 10G
Formatting 'flat.img', fmt=raw size=10737418240
如果我們ls則看到
ls -lh flat.img
-rw-r--r-- 1 root root 10G Jun 30 22:27 flat.img
但是並不真正占用10G
# du -h flat.img
0 flat.img
# qemu-img info flat.img
image: flat.img
file format: raw
virtual size: 10G (10737418240 bytes)
disk size: 0
我們可以用dd來制作sparse file
下面的命令制作的是非sparse的文件
# dd if=/dev/zero of=flat1.img bs=1024k count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.66135 s, 1.6 GB/s
block size是1024k，共1000個block
# qemu-img info flat1.img
image: flat1.img
file format: raw
virtual size: 1.0G (1048576000 bytes)
disk size: 1.0G
下面的命令制作的是sparse的文件
# dd if=/dev/zero of=flat2.img bs=1024k count=0 seek=2048
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000141061 s, 0.0 kB/s
# qemu-img info flat2.img
image: flat2.img
file format: raw
virtual size: 2.0G (2147483648 bytes)
disk size: 0
seek的意思是將文件的結尾設在那個地方。
如何copy一個sparse文件呢
# dd if=/dev/zero of=flat3.img bs=1024k count=1 seek=2048
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.0010721 s, 978 MB/s
# qemu-img info flat3.img
image: flat3.img
file format: raw
virtual size: 2.0G (2148532224 bytes)
disk size: 1.0M
# cp --sparse=never flat3.img flat3-never.img
這樣拷貝會占用整個2G空間
# qemu-img info flat3-never.img
image: flat3-never.img
file format: raw
virtual size: 2.0G (2148532224 bytes)
disk size: 2.0G
# cp --sparse=always flat3.img flat3-always.img
這樣拷貝原來寫入的1M的0也會被去掉
# qemu-img info flat3-always.img
image: flat3-always.img
file format: raw
virtual size: 2.0G (2148532224 bytes)
disk size: 0
# cp --sparse=always flat3-never.img flat3-never-always.img
這樣拷貝原來的2G都會被清理掉
# qemu-img info flat3-never-always.img
image: flat3-never-always.img
file format: raw
virtual size: 2.0G (2148532224 bytes)
disk size: 0
qcow2
qcow2是動態的，相對於raw來說，有下列的好處：
- 即便文件系統不支持sparse file，文件大小也很小
- Copy on write
- Snapshot
- 壓縮
- 加密
qcow2的格式如下：
2-Level loopup
qcow2的數據是存儲在data clusters里面的，每個cluster是512 byte sector
為了能夠管理這些cluster，qcow2保存了兩層的Table，L1 table指向L2 Table，L2 Table管理data cluster.
所以在image里面的offset會被解析成三部分，L1 Table Pointer先找L1，L1 Table Pointer+ offset[0]是L1中的一個entry，讀出來便是L2 Table Pointer, L2 Table Pointer + offset[1]是L2中的一個entry，讀出來便是data cluster pointer, data cluster pointer +offset[3]便是數據所在的位置。
Reference Count
每一個data cluster都有RefCount，因為可能有多個snapshot都引用每一個數據塊
Copy-on-write
這是backing file的用處，一個qcow2的image可以保存另一個disk image的改變，而不影響另一個image
root:/var/lib/nova/instances/5d6cb926-5237-4b73-a7b4-e9af851023e7# qemu-img info disk
image: disk
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 450M
cluster_size: 65536
backing file: /var/lib/nova/instances/_base/45a5886083c924b1fbe412b2ad92f6ce47381610
Format specific information:
compat: 1.1
lazy refcounts: false
root:/var/lib/nova/instances/5d6cb926-5237-4b73-a7b4-e9af851023e7# qemu-img info /var/lib/nova/instances/_base/45a5886083c924b1fbe412b2ad92f6ce47381610
image: /var/lib/nova/instances/_base/45a5886083c924b1fbe412b2ad92f6ce47381610
file format: raw
virtual size: 5.0G (5368709120 bytes)
disk size: 1.4G
上面的輸出表示有一個raw的image是/var/lib/nova/instances/_base/45a5886083c924b1fbe412b2ad92f6ce47381610，我們基於他生成一個虛擬機，但是不想改變這個image的內容，所以我們基於它生成了qcow2的image :/var/lib/nova/instances/5d6cb926-5237-4b73-a7b4-e9af851023e7/disk。
一開始新的image是空的，讀取的內容都從老的image里面讀取。
當一個data cluster被寫入，發生改變的時候，在新的image里面創建一個新的data cluster，這就是copy on write的意義。
Snapshot
snapshot其實也是copy on write的一種應用，但是兩者有微妙的不同。
廣義來講，有兩種snapshot，一中時internal snapshot，一種是external snapshot
internal snapshot是qcow2中的snapshot table所維護的snapshot，所有的snapshot都是在同一個文件中維護。
在monitor中，savevm, loadvm都是針對internal snapshot來操作的
我們創建一個虛擬機
# qemu-system-x86_64 -enable-kvm -name ubuntutest -m 2048 -hda ubuntutest.img -hdb ubuntutest1.img -boot menu=on -vnc :19 -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no
當我們在monitor中執行savevm后，ubuntutest.img和ubuntutest1.img都會在image內部打一個snapshot
$ qemu-img info ubuntutest.img
image: ubuntutest.img
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 2.1G
cluster_size: 65536
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 snapshot1 390M 2014-06-28 04:04:42 01:00:59.268
2 vm-20140630230902 239M 2014-06-30 23:09:02 00:04:07.783
Format specific information:
compat: 1.1
lazy refcounts: false
$ qemu-img info ubuntutest1.img
image: ubuntutest1.img
file format: qcow2
virtual size: 4.0G (4294967296 bytes)
disk size: 134M
cluster_size: 65536
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
2 vm-20140630230902 0 2014-06-30 23:09:02 00:04:07.783
Format specific information:
compat: 1.1
lazy refcounts: false
然而在monitor中info block的時候，還是指向的這兩個文件。
其中的原理是，當打一個snapshot后，會在snapshot table中建立一項，但是起初是空的，包含L1 table的一個復制，當L2 table或者data cluster改變的時候，則會將原來的數據復制一份，由snapshot的L1 table來維護，而原來的data cluster已經改變，在原地。
external snapshot則往往采用上面的copy on write的方法，當打snapshot的時候，將當前的image不再改變，創建一個新的image，以原來的image作為backing file，然后虛擬機使用新的image。
在monitor中，snapshot_blkdev ide0-hd1 ubuntutest-snapshot.img qcow2，就是采用的這種方式，當這個命令執行完畢后，在monitor中info block
而且我們發現，在HOST機器上多了一個文件
$ qemu-img info ubuntutest-snapshot.img
image: ubuntutest-snapshot.img
file format: qcow2
virtual size: 4.0G (4294967296 bytes)
disk size: 964K
cluster_size: 65536
backing file: ubuntutest1.img
backing file format: qcow2
Format specific information:
compat: 1.1
lazy refcounts: false
backing file可以是raw，也可以是qcow2，但是一旦打了snapshot，新的格式就是qcow2了。
兩者很相似，稍微的不同是：
- 對於internal snapshot, 剛打完snapshot的時候，原image集合是不變的，snapshot的集合是空的，接下來的操作，寫入在原image，將不變的加入snapshot集合
- 對於external snapshot，剛打完snapshot的時候，原image變成snapshot，snapshot集合是全集，新image是空的，接下來的操作，寫入在新image，將改變的加入新image的集合。
- it uses ‘qemu-img snapshot -c‘ if the domain is offline and –disk-only was not specified
- it uses qemu’s ‘savevm‘ if the domain is online and –disk-only was not specified
- it uses qemu’s ‘snapshot_blkdev‘ if the domain is online and –disk-only is specified
virsh有命令支持snapshot
對已internal snapshot
root:/etc/neutron# virsh snapshot-list instance-0000000a
Name Creation Time State
------------------------------------------------------------
root:/etc/neutron# virsh snapshot-create instance-0000000a
Domain snapshot 1404158715 created
root:/etc/neutron# virsh snapshot-list instance-0000000a
Name Creation Time State
------------------------------------------------------------
1404158715 2014-07-01 04:05:15 +0800 running
root# ps aux | grep instance-0000000a
libvirt+ 9057 0.0 1.2 6846900 821876 ? Sl Jun26 5:34 qemu-system-x86_64 -enable-kvm -name instance-0000000a -S -machine pc-i440fx-trusty,accel=kvm,usb=off -cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 5d6cb926-5237-4b73-a7b4-e9af851023e7 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2014.1,serial=80590690-87d2-e311-b1b0-a0481cabdfb4,uuid=5d6cb926-5237-4b73-a7b4-e9af851023e7 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0000000a.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/5d6cb926-5237-4b73-a7b4-e9af851023e7/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:fe:2a:41,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/5d6cb926-5237-4b73-a7b4-e9af851023e7/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 0.0.0.0:8 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
root 17709 0.0 0.0 10468 924 pts/1 S+ 04:06 0:00 grep --color=auto instance-0000000a
root# qemu-img info /var/lib/nova/instances/5d6cb926-5237-4b73-a7b4-e9af851023e7/disk
image: /var/lib/nova/instances/5d6cb926-5237-4b73-a7b4-e9af851023e7/disk
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 1.1G
cluster_size: 65536
backing file: /var/lib/nova/instances/_base/45a5886083c924b1fbe412b2ad92f6ce47381610
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 1404158715 725M 2014-07-01 04:05:15 117:35:52.160
Format specific information:
compat: 1.1
lazy refcounts: false
對於external snapshot
# virsh snapshot-create-as Instance01 snap1-Instance01 "Instance01 snapshot description" --diskspec vda,file=/home/cliu8/images/instance01-snapshot.img --disk-only --atomic
error: internal error: unable to execute QEMU command 'transaction': Could not open '/home/cliu8/images/instance01.img': Could not open '/home/cliu8/images/instance01.img': Permission denied: Permission denied
從網上查，是因為下面的問題：
-------------------------------------------------------------------------------------
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1004606
Bug Description
When you attempt to create a virtual machine snapshot onto a separate disk, this fails with an error message. The error message is different depending on whether you use snapshot-create or snapshot-create-as but both approaches fail.
The intention is to be able to take a backup of a live VM by freezing the running image file and applying snapshot deltas to a separate file so the backup can save the filesystem image without it being modified during the backup. (i.e. standard practice in VM world)
Format being used is QCOW2 for the disk file which supports snapshots. Manually using qemu-img to create a snapshot on the file does work without any problems.
If you use snapshot-create-as :
snapshot-create-as winxppro3 snapname --disk-only --diskspec hda,snapshot=external,file=/srv/virtual-machines/tester/snap01.qcow2
error: internal error unable to execute QEMU command 'blockdev-snapshot-sync': An undefined error has ocurred
Or if you use snapshot-create and an XML file specification :
virsh # snapshot-create winxppro3 snapspec.xml
error: argument unsupported: unable to handle disk requests in snapshot
snapspec.xml is :
<domainsnapshot>
<name>snapname</name>
<description>test</description>
<disks>
<disk name='hda' snapshot='external'>
<source file='/srv/virtual-machines/tester/snap01.qcow2'/>
</disk>
</disks>
</domainsnapshot>
PC specification is :
<domain type='kvm' id='2'>
<name>winxppro3</name>
<uuid>b6b35d98-dc3a-e03d-031b-906ae079620f</uuid>
<memory>524288</memory>
<currentMemory>524288</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='pc-0.14'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='localtime'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/srv/virtual-machines/tester/winxp2.qcow2'/>
<target dev='hda' bus='ide'/>
<alias name='ide0-0-0'/>
<address type='drive' controller='0' bus='0' unit='0'/>
</disk>
etc. etc.
The path, excluding extension, is the same as the original image.
Unfortunately the extension can be chosen by the user:
"Name
The name for this snapshot. If the name is specified when initially creating the snapshot, then the snapshot will have that particular name. If the name is omitted when initially creating the snapshot, then libvirt will make up a name for the snapshot, based on the time when it was created."
(from http://libvirt.org/formatsnapshot.html) with the name parameter)
Assuming my_dom disk image is stored under /nfs/diskimages/my_dom.img, a command like the following:
# snapshot-create-as my_dom my_snap --disk-only
will create /nfs/diskimages/my_dom.my_snap changing domain definition XML to use this file instead of /nfs/diskimages/my_dom.img (/nfs/diskimages/my_dom.img will be a backing file for /nfs/diskimages/my_dom.my_snap)
However I fear it's not that simple because even if I try to use a snapshot name like mysnap.img, snaphot still fails because the original image name is removed from the apparmour profile dinamically created/maintained by libvirt under /etc/apparmor.d/libvirt. The original filename is replaced with the new image name.
So, to sum up, I think the following might be needed in order to make disk-only snapshot work
1) virt-aa-helper (/etc/apparmor.d/usr.lib.libvirt.virt-aa-helper) should be able to read virtual machine image files even if the extension isn't imq/qcow2/...
2) dynamically created profiles for libvirt (/etc/apparmor.d/libvirt/libvirt-XXXX.files) should retain the old image filename
Please, be aware that after the "snapshot-create" command fails, the corresponding profile under /etc/apparmor.d/libvirt/ isn't coherent anymore with the real filename for virtual images.
I found a that looks better than deactivating apparmor.
I found here ( http://libvirt.org/drvqemu.html#securitysvirtaa ) the information that Apparmor is „just“ used for protecting the vm host and that there is a TEMPLATE under /etc/apparmor.d/libvirt/ that can be modified. In that TEMPLATE I included one of my own rules and under /etc/apparmor.d/local/usr.sbin.libvirtd i added a similar rule.
Yes Theodor, please share your apparmor-rules :)
For the moment i am following this guide to disable just the libvirt-apparmor-profile:
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/hypervisor-kvm-install-flow.html#hypervisor-host-install-security-policies "Configure Apparmor (Ubuntu)"
$ sudo ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/
$ sudo ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/
$ sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
$ sudo apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
Stop running virtual machines.
$ sudo service apparmor restart
$ sudo apparmor_status
Start machines again.
In the /etc/apparmor.d/local/usr.sbin.libvirtd file I just created one rule to give libvirtd read'n'write access to the images in my storage pool with the following line:
"/var/lib/libvirt/images/*.img" rw,
As preliminary: I have created my own naming convention for my overlays, these are used for incremental backups to another server. This convention can be found in my abstractation and has to be adjusted to your own needs.
First of all I've created my own abstraction as /etc/apparmor.d/local/abstraction-libvirt-storage. This file gives the clients access to the important images like that:
"/var/lib/libvirt/images/*.base.img" rw,
"/var/lib/libvirt/images/*.base.img" rw,
"/var/lib/libvirt/images/*.stable_overlay.img" rw,
"/var/lib/libvirt/images/*.running.img" rw,
The /etc/apparmor.d/libvirt/TEMPLATE file is a source for all rule files in /etc/apparmor.d/libvirt/. There you need to source the abstraction-libvirt-storage so the TEMPLATE looks similar to this one (adjust to your own needs):
profile LIBVIRT_TEMPLATE {
#include <abstractions/libvirt-qemu>
#include <local/abstractation-libvirt-storage>
}
It is also possible to put the information of the abstraction-libvirt-storage file directly into the TEMPLATE but a change on some of the rules would require to edit multiple files ( /etc/apparmor.d/libvirt/*)
I hope this will help. This adjustments should be fine for safety requirement, because the host should still be secured against guests and thats the only thing you can do with libvirt+apparmor.
http://libvirt.org/drvqemu.html#securitysvirtaa
Configure Apparmor (Ubuntu)
-
Check to see whether AppArmor is installed on your machine. If not, you can skip this section.
In Ubuntu AppArmor is installed and enabled by default. You can verify this with:
$ dpkg --list 'apparmor'
-
Disable the AppArmor profiles for libvirt
$ ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/
$ ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/
$ apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
$ apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1096125
virsh create-snapshot fails
Bug Description
Hello,
i have a plain installation of Ubuntu 12.10 server,
i installed package ubuntu-virt-server and added the user to the kvm and libvirtd group. (qemu-kvm 1.2 libvirt 0.9.13)
After that i can run kvm virtual machines.
Now i am trying to get a snapshot of the disk (first step to achieve live backup of virtual machines)
virsh snapshot-create-as [vmname] snapshot1 "snapshot" --disk-only --atomic
but i am getting the following error:
error: internal error unable to execute QEMU command 'transaction': Could not open '/var/lib/libvirt/images/ubu1204.snapshot1'
(i even tryed with permission 777 )
Hi Serge,
i made a snapshot after disabling apparmor and it works!
Here are the commands used:
/etc/init.d/apparmor stop
update-rc.d -f apparmor remove
reboot now
virsh snapshot-create-as ubu-server-64-10.04.3 snap1 --disk-only
So i changed the target package of the bug to apparmor
Thank you again
affects:
kvm (Ubuntu) → apparmor (Ubuntu)
----------------------------------------------------------------------------
我們可以在/etc/libvirt/qemu.conf將apparmor去掉
security_driver = "none"
重啟service libvirt-bin restart
重啟虛擬機
virsh destroy Instance02
virsh start Instance02
# virsh snapshot-create-as Instance02 snap1-Instance02 "Instance02 snapshot description" --diskspec vda,file=/home/cliu8/images/instance02-snapshot.img --disk-only --atomic
Domain snapshot snap1-Instance02 created
# qemu-img info instance02-snapshot.img
image: instance02-snapshot.img
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 2.2M
cluster_size: 65536
backing file: /home/cliu8/images/instance02.img
backing file format: qcow2
Format specific information:
compat: 1.1
lazy refcounts: false
在創建一個
# virsh snapshot-create-as Instance02 snap2-Instance02 "Instance02 snapshot description" --diskspec vda,file=/home/cliu8/images/instance02-snapshot2.img --disk-only --atomic
Domain snapshot snap2-Instance02 created
# virsh snapshot-list Instance02 --tree
snap1-Instance02
|
+- snap2-Instance02
root:/home/cliu8/images# qemu-img info instance02-snapshot.img
image: instance02-snapshot.img
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 2.2M
cluster_size: 65536
backing file: /home/cliu8/images/instance02.img
backing file format: qcow2
Format specific information:
compat: 1.1
lazy refcounts: false
root:/home/cliu8/images# qemu-img info instance02-snapshot2.img
image: instance02-snapshot2.img
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 196K
cluster_size: 65536
backing file: /home/cliu8/images/instance02-snapshot.img
backing file format: qcow2
Format specific information:
compat: 1.1
lazy refcounts: false
看了我們需要單獨的一節來闡述snapshot和AppArmor security deriver了
Convert, compress, encrypt, enlarge
image格式之間可以轉換
raw可以轉換為qcow2
root:/home/cliu8/images# qemu-img info flat1.img
image: flat1.img
file format: raw
virtual size: 1.0G (1048576000 bytes)
disk size: 1.0G
root:/home/cliu8/images# qemu-img convert -f raw -O qcow2 flat1.img flat1.qcow2
root:/home/cliu8/images# qemu-img info flat1.qcow2
image: flat1.qcow2
file format: qcow2
virtual size: 1.0G (1048576000 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
有時候qcow2也可以轉換為qcow2，轉換的過程中，沒用的data cluster就被去掉了
root:/home/cliu8/images# qemu-img info ubuntutest.img
image: ubuntutest.img
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 2.1G
cluster_size: 65536
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 snapshot1 390M 2014-06-28 04:04:42 01:00:59.268
2 vm-20140630230902 239M 2014-06-30 23:09:02 00:04:07.783
Format specific information:
compat: 1.1
lazy refcounts: false
root:/home/cliu8/images# qemu-img convert -f qcow2 -O qcow2 ubuntutest.img ubuntutest.qcow2
root:/home/cliu8/images# qemu-img info ubuntutest.qcow2
image: ubuntutest.qcow2
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 1.4G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
還可以壓縮
root:/home/cliu8/images# qemu-img convert -c -f qcow2 -O qcow2 ubuntutest.img ubuntutest-compress.qcow2
root:/home/cliu8/images# qemu-img info ubuntutest-compress.qcow2
image: ubuntutest-compress.qcow2
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 465M
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
還可以加密
root:/home/cliu8/images# qemu-img convert -o encryption -f qcow2 -O qcow2 ubuntutest.img ubuntutest-encrypt.qcow2
Disk image 'ubuntutest-encrypt.qcow2' is encrypted.
password:
root:/home/cliu8/images# qemu-img info ubuntutest-encrypt.qcow2
image: ubuntutest-encrypt.qcow2
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 1.4G
encrypted: yes
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
我們運行一個虛擬機
# qemu-system-x86_64 -enable-kvm -name ubuntutest -m 2048 -hda ubuntutest-encrypt.qcow2 -boot menu=on -vnc :19 -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=n
發現一開始虛擬機並不啟動
進入monitor輸入用戶名密碼，方才啟動
也可以在monitor中修改密碼
block_passwd ide0-hd0 newpassword
image可以擴大，首先必須instance在shutdown的情況下，另外是必須raw format才能enlarge，最后擴大的空間既不會被partition，也不會被format
# qemu-img resize ubuntutest.img +10G
qemu-img: Can't resize an image which has snapshots
qemu-img: This image does not support resize
root:/home/cliu8/images# qemu-img resize ubuntu-14.04.qcow2 +10G
Image resized.
root:/home/cliu8/images# qemu-img info ubuntu-14.04.qcow2
image: ubuntu-14.04.qcow2
file format: qcow2
virtual size: 15G (16106127360 bytes)
disk size: 461M
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
看了qcow2如果沒有snapshot也能enlarge