From Fedora Project Wiki

m (Add links to test case stubs)
m (Changed category)
 
(12 intermediate revisions by 6 users not shown)
Line 17: Line 17:
=== Who's available ===
=== Who's available ===


[[User:FIXME|FIXME]] is your host for today.
[[User:Crobinso|Cole Robinson]] and [[User:Kwolf|Kevin Wolf]] (IRC nick kwolf, GMT+2h) are your hosts for today.


The following people have also agreed to be available for testing, workarounds, bug fixes, and general discussion:
The following people have also agreed to be available for testing, workarounds, bug fixes, and general discussion:
* ''add your name here''


=== What's needed to test ===
=== What's needed to test ===
Line 27: Line 29:


=== Test Cases ===
=== Test Cases ===
{|
! TEST !! METHOD
|-
| virt-install w/ qcow2
||
virt-install can create qcow2 images at install time via the '--disk format='
option:
virt-install --connect qemu:///system \
              --name rawhide-qcow2 \
              --ram 1024 \
              --disk path=/var/lib/libvirt/images/rawhide.qcow2,format=qcow2,size=6 \
              --location http://download.fedoraproject.org/pub/fedora/linux/development/x86_64/os \
              --os-variant fedora12
virt-install can only create QCOW2 images in a libvirt managed directory
(storage pool), so trying to create /home/foouser/myvm.qcow2 may error unless
you have taught libvirt about your home directory. You can do this via
virt-manager: Edit->Host Details->Storage-> '+' Button to add a directory
storage pool. QCOW2 images can also be provisioned from the 'Storage' section
by selecting 'New Volume'
|-
| virt-manager w/ qcow2
||
Similarly, a qcow2 install can be done with virt-manager.
# Open virt-manager, click 'New'
# Enter options as necessary until you reach the 'Storage' screen
# Click 'Select managed or existing storage', then click 'Browse'
# Select storage pool 'default', then click 'New Volume'
# Enter a new filename and size, but select Format 'qcow2', click 'Create Volume'
# Select the newly created volume and click 'Choose Volume'
# Continue with the installation
|-
| qemu-img convert from raw to qcow2
||
An existing disk image can be converted to qcow2 using 'qemu-img':
cd /var/lib/libvirt/images
qemu-img convert -O qcow2 <original image> <new image name>
virsh pool-refresh default
This will not alter or remove the original disk image. 'pool-refresh' is
required for libvirt to notice the change. To point your VM at the qcow2 image,
you can use 'virsh edit <vm name>', and change the disk paths.
|-
| Backing files
||
An existing disk image can be used as a readonly 'backing store' for a new
image. The new image provides COW access to the original image: only changes
are stored in the new image (the original image is NOT altered in anyway).
This is useful if a user wants to test possibly dangerous changes to a valuable
disk image.
This can be done via libvirt. You will need to create an XML file for the new image:


Things to test, roughly in dependency order:
cat << __EOF__ >> new.xml
<volume>
  <name>new.img</name>
  <!-- Amount of space to store changes -->
  <capacity>1000000000</capacity>
  <allocation>0</allocation>
  <target>
    <format type='qcow2'/>
  </target>
  <backingStore>
    <path>/var/lib/libvirt/images/youroriginal.img</path>
  </backingStore>
</volume>
__EOF__


# [[QA:Testcase virt-install using qcow2]]
Then run:
# [[QA:Testcase virt-manager install using qcow2]]
virsh vol-create --pool default new.xml
# [[QA:Testcase qemu-img convert from raw to qcow2]]
 
# [[QA:Testcase qemu-img create snapshot]]
You can then create a VM pointing at 'new.img', or repoint an existing image at the new file using 'virsh edit <vm name>'
 
|}
 
=== Advanced aspects ===
 
If you want to play a bit more with qcow2 and the test cases suggested above are not enough for you, there are some additional features that cannot be accessed with the management tools (so they are not top priority to be tested), but you still can use them by invoking qemu-img and qemu manually.
 
When creating images with qemu-img, you can change some default options using the -o parameter. For example you could create a fairly non-standard image using <code>qemu-img create -f qcow2 -o encryption,cluster_size=32k,backing_file=base.vmdk image.qcow2 10G</code>. To get an overview of the supported options, you can use <code>qemu-img create -f qcow2 -o ?</code>.
 
The following list contains some suggestions on what you could test:
* Encrypted images (<code>-o encryption</code>)
* Varying cluster sizes (<code>-o cluster_size=size</code> where size is between 512 and 64k). Smaller cluster can save some space on almost empty disks, larger clusters are faster usually.
* Backing files (<code>-o backing_file=file</code>). The new image is based on the given backing file and only differences are saved into the qcow2 file. Try usinh different formats for the backing file, it doesn't need to be qcow2.
* Commit back the changes from a qcow2 image to its backing file (<code>qemu-img commit</code> or the <code>commit</code> command in the qemu monitor)
* Snapshots: You can either snapshot the disk of a turned off VM (<code>qemu-img snapshot -c my_snapshot disk.qcow2</code>) or use the qemu monitor to save the state of a running VM (<code>savevm my_snapshot</code>). In the former case, you can revert the disk to the saved state using <code>qemu-img snapshot -a my_snapshot.qcow2</code>. Using the qemu monitor (<code>loadvm my_snapshot</code>) you restore the complete VM state as it was when you saved the snapshot. Alternatively, you can also use the -loadvm option on the qemu command line to start a VM using a previously saved snapshot.
* Compressed images: When converting an image, you can have the resulting qcow2 image compressed (<code>qemu-img convert -O qcow2 -c ...</code>)
* Combine things: Snapshots on an encrypted image with a compressed backing file...
 
If you suspect that something has gone wrong with your image and you want to check it, you can try <code>qemu-img check disk.qcow2</code>.


=== Issues that were identified ===
=== Issues that were identified ===
Line 40: Line 138:
|-style="color: white; background-color: #3074c2; font-weight: bold"  
|-style="color: white; background-color: #3074c2; font-weight: bold"  
| Tester || Description || Bug references || Status
| Tester || Description || Bug references || Status
|-  
|-
| || || [http://bugzilla.redhat.com/XXXXXX #XXXXX] || '''ASSIGNED'''
| phan || VM cannot boot from the disk converted by qemu-img || [http://bugzilla.redhat.com/523948 #523948] || '''NEEDINFO'''
|}
|-
| jbao ||  VM cannot boot from the backing disk img || [http://bugzilla.redhat.com/525362 #525362] || '''NEEDINFO'''
|
 


[[Category:Test Days]]
[[Category:Fedora_12_Test_Days]]
[[Category:Virtualization]]
[[Category:Virtualization]]

Latest revision as of 14:21, 3 February 2010

DATE TIME WHERE
Thursday Sep 17, 2009 All day #fedora-test-day (webchat)

What to test?[edit]

This part of today's Fedora Test Day will focus on testing virt-manager, libvirt and qemu-kvm support for the qcow2 image format.

This is related to the KVM qcow2 Performance feature in Fedora 12. If we're to advertise the format's improved performance, we better test that people can use the format!

If you come to this page after the test day is completed, your testing is still valuable, and you can use the information on this page to test qcow2 support and provide feedback.

Who's available[edit]

Cole Robinson and Kevin Wolf (IRC nick kwolf, GMT+2h) are your hosts for today.

The following people have also agreed to be available for testing, workarounds, bug fixes, and general discussion:

  • add your name here

What's needed to test[edit]

Test Cases[edit]

TEST METHOD
virt-install w/ qcow2

virt-install can create qcow2 images at install time via the '--disk format=' option:

virt-install --connect qemu:///system \
             --name rawhide-qcow2 \
             --ram 1024 \
             --disk path=/var/lib/libvirt/images/rawhide.qcow2,format=qcow2,size=6 \
             --location http://download.fedoraproject.org/pub/fedora/linux/development/x86_64/os \
             --os-variant fedora12

virt-install can only create QCOW2 images in a libvirt managed directory (storage pool), so trying to create /home/foouser/myvm.qcow2 may error unless you have taught libvirt about your home directory. You can do this via virt-manager: Edit->Host Details->Storage-> '+' Button to add a directory storage pool. QCOW2 images can also be provisioned from the 'Storage' section by selecting 'New Volume'

virt-manager w/ qcow2

Similarly, a qcow2 install can be done with virt-manager.

  1. Open virt-manager, click 'New'
  2. Enter options as necessary until you reach the 'Storage' screen
  3. Click 'Select managed or existing storage', then click 'Browse'
  4. Select storage pool 'default', then click 'New Volume'
  5. Enter a new filename and size, but select Format 'qcow2', click 'Create Volume'
  6. Select the newly created volume and click 'Choose Volume'
  7. Continue with the installation
qemu-img convert from raw to qcow2

An existing disk image can be converted to qcow2 using 'qemu-img':

cd /var/lib/libvirt/images
qemu-img convert -O qcow2 <original image> <new image name>
virsh pool-refresh default

This will not alter or remove the original disk image. 'pool-refresh' is required for libvirt to notice the change. To point your VM at the qcow2 image, you can use 'virsh edit <vm name>', and change the disk paths.

Backing files

An existing disk image can be used as a readonly 'backing store' for a new image. The new image provides COW access to the original image: only changes are stored in the new image (the original image is NOT altered in anyway). This is useful if a user wants to test possibly dangerous changes to a valuable disk image.

This can be done via libvirt. You will need to create an XML file for the new image:

cat << __EOF__ >> new.xml
<volume>
  <name>new.img</name>
  <capacity>1000000000</capacity>
  <allocation>0</allocation>
  <target>
    <format type='qcow2'/>
  </target>
  <backingStore>
    <path>/var/lib/libvirt/images/youroriginal.img</path>
  </backingStore>
</volume>
__EOF__

Then run:

virsh vol-create --pool default new.xml

You can then create a VM pointing at 'new.img', or repoint an existing image at the new file using 'virsh edit <vm name>'

Advanced aspects[edit]

If you want to play a bit more with qcow2 and the test cases suggested above are not enough for you, there are some additional features that cannot be accessed with the management tools (so they are not top priority to be tested), but you still can use them by invoking qemu-img and qemu manually.

When creating images with qemu-img, you can change some default options using the -o parameter. For example you could create a fairly non-standard image using qemu-img create -f qcow2 -o encryption,cluster_size=32k,backing_file=base.vmdk image.qcow2 10G. To get an overview of the supported options, you can use qemu-img create -f qcow2 -o ?.

The following list contains some suggestions on what you could test:

  • Encrypted images (-o encryption)
  • Varying cluster sizes (-o cluster_size=size where size is between 512 and 64k). Smaller cluster can save some space on almost empty disks, larger clusters are faster usually.
  • Backing files (-o backing_file=file). The new image is based on the given backing file and only differences are saved into the qcow2 file. Try usinh different formats for the backing file, it doesn't need to be qcow2.
  • Commit back the changes from a qcow2 image to its backing file (qemu-img commit or the commit command in the qemu monitor)
  • Snapshots: You can either snapshot the disk of a turned off VM (qemu-img snapshot -c my_snapshot disk.qcow2) or use the qemu monitor to save the state of a running VM (savevm my_snapshot). In the former case, you can revert the disk to the saved state using qemu-img snapshot -a my_snapshot.qcow2. Using the qemu monitor (loadvm my_snapshot) you restore the complete VM state as it was when you saved the snapshot. Alternatively, you can also use the -loadvm option on the qemu command line to start a VM using a previously saved snapshot.
  • Compressed images: When converting an image, you can have the resulting qcow2 image compressed (qemu-img convert -O qcow2 -c ...)
  • Combine things: Snapshots on an encrypted image with a compressed backing file...

If you suspect that something has gone wrong with your image and you want to check it, you can try qemu-img check disk.qcow2.

Issues that were identified[edit]

Tester Description Bug references Status
phan VM cannot boot from the disk converted by qemu-img #523948 NEEDINFO
jbao VM cannot boot from the backing disk img #525362 NEEDINFO