When I create the VM's image disk, I am not asked to select the following type of disk. What is the default value ? Thanks. QCOW2 Formatted Virtual Machine Storage QCOW2 is a storage format for virtual disks. QCOW stands for QEMU copy-on-write. The QCOW2 format decouples the physical storage layer from the virtual layer by adding a mapping between logical and physical blocks. Each logical block is mapped to its physical offset, which enables storage over-commitment and virtual machine snapshots, where each QCOW volume only represents changes made to an underlying virtual disk. The initial mapping points all logical blocks to the offsets in the backing file or volume. When a virtual machine writes data to a QCOW2 volume after a snapshot, the relevant block is read from the backing volume, modified with the new information and written into a new snapshot QCOW2 volume. Then the map is updated to point to the new place. Raw The raw storage format has a performance advantage over QCOW2 in that no formatting is applied to virtual disks stored in the raw format. Virtual machine data operations on virtual disks stored in raw format require no additional work from hosts. When a virtual machine writes data to a given offset in its virtual disk, the I/O is written to the same offset on the backing file or logical volume. Raw format requires that the entire space of the defined image be preallocated unless using externally managed thin provisioned LUNs from a storage array.
On Wednesday, 22 September 2021 09:55:26 CEST Tommy Sway wrote:
When I create the VM's image disk, I am not asked to select the following type of disk.
Actually you are, it's "Allocation Policy" drop down menu. Thin provisioned == qcow format Preallocated == raw
What is the default value ?
Thin provisioned, i.e. qcow.
Thanks.
QCOW2 Formatted Virtual Machine Storage
QCOW2 is a storage format for virtual disks. QCOW stands for QEMU copy-on-write. The QCOW2 format decouples the physical storage layer from the virtual layer by adding a mapping between logical and physical blocks. Each logical block is mapped to its physical offset, which enables storage over-commitment and virtual machine snapshots, where each QCOW volume only represents changes made to an underlying virtual disk.
The initial mapping points all logical blocks to the offsets in the backing file or volume. When a virtual machine writes data to a QCOW2 volume after a snapshot, the relevant block is read from the backing volume, modified with the new information and written into a new snapshot QCOW2 volume. Then the map is updated to point to the new place.
Raw
The raw storage format has a performance advantage over QCOW2 in that no formatting is applied to virtual disks stored in the raw format. Virtual machine data operations on virtual disks stored in raw format require no additional work from hosts. When a virtual machine writes data to a given offset in its virtual disk, the I/O is written to the same offset on the backing file or logical volume.
Raw format requires that the entire space of the defined image be preallocated unless using externally managed thin provisioned LUNs from a storage array.
You mean if it's pre-allocated, it must be RAW, not Qcow2? The documentation only states that RAW must be pre-allocated, but it does not say that qCOW2 cannot use pre-allocation. -----Original Message----- From: Vojtech Juranek <vjuranek@redhat.com> Sent: Wednesday, September 22, 2021 6:04 PM To: users@ovirt.org Cc: Tommy Sway <sz_cuitao@163.com> Subject: Re: [ovirt-users] about the vm disk type On Wednesday, 22 September 2021 09:55:26 CEST Tommy Sway wrote:
When I create the VM's image disk, I am not asked to select the following type of disk.
Actually you are, it's "Allocation Policy" drop down menu. Thin provisioned == qcow format Preallocated == raw
What is the default value ?
Thin provisioned, i.e. qcow.
Thanks.
QCOW2 Formatted Virtual Machine Storage
QCOW2 is a storage format for virtual disks. QCOW stands for QEMU copy-on-write. The QCOW2 format decouples the physical storage layer from the virtual layer by adding a mapping between logical and physical
blocks.
Each logical block is mapped to its physical offset, which enables storage over-commitment and virtual machine snapshots, where each QCOW volume only represents changes made to an underlying virtual disk.
The initial mapping points all logical blocks to the offsets in the backing file or volume. When a virtual machine writes data to a QCOW2 volume after a snapshot, the relevant block is read from the backing volume, modified with the new information and written into a new snapshot QCOW2 volume. Then the map is updated to point to the new place.
Raw
The raw storage format has a performance advantage over QCOW2 in that no formatting is applied to virtual disks stored in the raw format. Virtual machine data operations on virtual disks stored in raw format require no additional work from hosts. When a virtual machine writes data to a given offset in its virtual disk, the I/O is written to the same offset on the backing file or logical volume.
Raw format requires that the entire space of the defined image be preallocated unless using externally managed thin provisioned LUNs from a storage array.
For example : And I check the file on the storage: [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# cat 9e4dc022-c450-4f85-89f5-233fa41c07d0.meta CAP=10737418240 CTIME=1632305740 DESCRIPTION={"DiskAlias":"test09222_Disk1","DiskDescription":""} DISKTYPE=DATA DOMAIN=f77091d9-aabc-42db-87b1-b8299765482e FORMAT=RAW GEN=0 IMAGE=51dcbfae-1100-4e43-9e0a-bb8c578623d7 LEGALITY=LEGAL PUUID=00000000-0000-0000-0000-000000000000 TYPE=SPARSE VOLTYPE=LEAF EOF [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# ll total 1025 -rw-rw----. 1 vdsm kvm 10737418240 Sep 22 18:15 9e4dc022-c450-4f85-89f5-233fa41c07d0 -rw-rw----. 1 vdsm kvm 1048576 Sep 22 18:15 9e4dc022-c450-4f85-89f5-233fa41c07d0.lease -rw-r--r--. 1 vdsm kvm 303 Sep 22 18:15 9e4dc022-c450-4f85-89f5-233fa41c07d0.meta [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# du -h ./9e4dc022-c450-4f85-89f5-233fa41c07d0 0 ./9e4dc022-c450-4f85-89f5-233fa41c07d0 [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# -----Original Message----- From: users-bounces@ovirt.org <mailto:users-bounces@ovirt.org> <users-bounces@ovirt.org <mailto:users-bounces@ovirt.org> > On Behalf Of Tommy Sway Sent: Wednesday, September 22, 2021 6:07 PM To: 'Vojtech Juranek' <vjuranek@redhat.com <mailto:vjuranek@redhat.com> >; users@ovirt.org <mailto:users@ovirt.org> Subject: [ovirt-users] Re: about the vm disk type You mean if it's pre-allocated, it must be RAW, not Qcow2? The documentation only states that RAW must be pre-allocated, but it does not say that qCOW2 cannot use pre-allocation. -----Original Message----- From: Vojtech Juranek < <mailto:vjuranek@redhat.com> vjuranek@redhat.com> Sent: Wednesday, September 22, 2021 6:04 PM To: <mailto:users@ovirt.org> users@ovirt.org Cc: Tommy Sway < <mailto:sz_cuitao@163.com> sz_cuitao@163.com> Subject: Re: [ovirt-users] about the vm disk type On Wednesday, 22 September 2021 09:55:26 CEST Tommy Sway wrote:
When I create the VM's image disk, I am not asked to select the
following type of disk.
Actually you are, it's "Allocation Policy" drop down menu. Thin provisioned == qcow format Preallocated == raw
What is the default value ?
Thin provisioned, i.e. qcow.
Thanks.
QCOW2 Formatted Virtual Machine Storage
QCOW2 is a storage format for virtual disks. QCOW stands for QEMU
copy-on-write. The QCOW2 format decouples the physical storage layer
from the virtual layer by adding a mapping between logical and
physical
blocks.
Each logical block is mapped to its physical offset, which enables
storage over-commitment and virtual machine snapshots, where each QCOW
volume only represents changes made to an underlying virtual disk.
The initial mapping points all logical blocks to the offsets in the
backing file or volume. When a virtual machine writes data to a QCOW2
volume after a snapshot, the relevant block is read from the backing
volume, modified with the new information and written into a new
snapshot QCOW2 volume. Then the map is updated to point to the new place.
Raw
The raw storage format has a performance advantage over QCOW2 in that
no formatting is applied to virtual disks stored in the raw format.
Virtual machine data operations on virtual disks stored in raw format
require no additional work from hosts. When a virtual machine writes
data to a given offset in its virtual disk, the I/O is written to the
same offset on the backing file or logical volume.
Raw format requires that the entire space of the defined image be
preallocated unless using externally managed thin provisioned LUNs
from a storage array.
_______________________________________________ Users mailing list -- <mailto:users@ovirt.org> users@ovirt.org To unsubscribe send an email to <mailto:users-leave@ovirt.org> users-leave@ovirt.org Privacy Statement: <https://www.ovirt.org/privacy-policy.html> https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: <https://www.ovirt.org/community/about/community-guidelines/> https://www.ovirt.org/community/about/community-guidelines/ List Archives: <https://lists.ovirt.org/archives/list/users@ovirt.org/message/JGJX4VUOYVBG6AWPKWVMILXINNOFFO2V/> https://lists.ovirt.org/archives/list/users@ovirt.org/message/JGJX4VUOYVBG6A...
file-based domains use RAW for both settings, thin-provisioned on block domain will use qcow2, otherwise RAW will be used On Wed, Sep 22, 2021 at 1:22 PM Tommy Sway <sz_cuitao@163.com> wrote:
For example :
And I check the file on the storage:
[root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# cat 9e4dc022-c450-4f85-89f5-233fa41c07d0.meta
CAP=10737418240
CTIME=1632305740
DESCRIPTION={"DiskAlias":"test09222_Disk1","DiskDescription":""}
DISKTYPE=DATA
DOMAIN=f77091d9-aabc-42db-87b1-b8299765482e
*FORMAT=RAW*
GEN=0
IMAGE=51dcbfae-1100-4e43-9e0a-bb8c578623d7
LEGALITY=LEGAL
PUUID=00000000-0000-0000-0000-000000000000
TYPE=SPARSE
VOLTYPE=LEAF
EOF
[root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]#
[root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]#
[root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# ll
total 1025
-rw-rw----. 1 vdsm kvm 10737418240 Sep 22 18:15 9e4dc022-c450-4f85-89f5-233fa41c07d0
-rw-rw----. 1 vdsm kvm 1048576 Sep 22 18:15 9e4dc022-c450-4f85-89f5-233fa41c07d0.lease
-rw-r--r--. 1 vdsm kvm 303 Sep 22 18:15 9e4dc022-c450-4f85-89f5-233fa41c07d0.meta
[root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]#
[root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]#
[root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# du -h ./9e4dc022-c450-4f85-89f5-233fa41c07d0
0 ./9e4dc022-c450-4f85-89f5-233fa41c07d0
[root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]#
[root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]#
-----Original Message----- From: users-bounces@ovirt.org <users-bounces@ovirt.org> On Behalf Of Tommy Sway Sent: Wednesday, September 22, 2021 6:07 PM To: 'Vojtech Juranek' <vjuranek@redhat.com>; users@ovirt.org Subject: [ovirt-users] Re: about the vm disk type
You mean if it's pre-allocated, it must be RAW, not Qcow2?
The documentation only states that RAW must be pre-allocated, but it does not say that qCOW2 cannot use pre-allocation.
-----Original Message-----
From: Vojtech Juranek <vjuranek@redhat.com>
Sent: Wednesday, September 22, 2021 6:04 PM
To: users@ovirt.org
Cc: Tommy Sway <sz_cuitao@163.com>
Subject: Re: [ovirt-users] about the vm disk type
On Wednesday, 22 September 2021 09:55:26 CEST Tommy Sway wrote:
When I create the VM's image disk, I am not asked to select the
following type of disk.
Actually you are, it's "Allocation Policy" drop down menu.
Thin provisioned == qcow format
Preallocated == raw
What is the default value ?
Thin provisioned, i.e. qcow.
Thanks.
QCOW2 Formatted Virtual Machine Storage
QCOW2 is a storage format for virtual disks. QCOW stands for QEMU
copy-on-write. The QCOW2 format decouples the physical storage layer
from the virtual layer by adding a mapping between logical and
physical
blocks.
Each logical block is mapped to its physical offset, which enables
storage over-commitment and virtual machine snapshots, where each QCOW
volume only represents changes made to an underlying virtual disk.
The initial mapping points all logical blocks to the offsets in the
backing file or volume. When a virtual machine writes data to a QCOW2
volume after a snapshot, the relevant block is read from the backing
volume, modified with the new information and written into a new
snapshot QCOW2 volume. Then the map is updated to point to the new place.
Raw
The raw storage format has a performance advantage over QCOW2 in that
no formatting is applied to virtual disks stored in the raw format.
Virtual machine data operations on virtual disks stored in raw format
require no additional work from hosts. When a virtual machine writes
data to a given offset in its virtual disk, the I/O is written to the
same offset on the backing file or logical volume.
Raw format requires that the entire space of the defined image be
preallocated unless using externally managed thin provisioned LUNs
from a storage array.
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/JGJX4VUOYVBG6A... _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/JMXUYJXYWNHZ75...
I also have block storage on my environment. How do I observe the type of a vm image (LV)? From: Benny Zlotnik <bzlotnik@redhat.com> Sent: Wednesday, September 22, 2021 7:30 PM To: Tommy Sway <sz_cuitao@163.com> Cc: Vojtech Juranek <vjuranek@redhat.com>; users <users@ovirt.org> Subject: Re: [ovirt-users] Re: about the vm disk type file-based domains use RAW for both settings, thin-provisioned on block domain will use qcow2, otherwise RAW will be used On Wed, Sep 22, 2021 at 1:22 PM Tommy Sway <sz_cuitao@163.com <mailto:sz_cuitao@163.com> > wrote: For example : And I check the file on the storage: [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# cat 9e4dc022-c450-4f85-89f5-233fa41c07d0.meta CAP=10737418240 CTIME=1632305740 DESCRIPTION={"DiskAlias":"test09222_Disk1","DiskDescription":""} DISKTYPE=DATA DOMAIN=f77091d9-aabc-42db-87b1-b8299765482e FORMAT=RAW GEN=0 IMAGE=51dcbfae-1100-4e43-9e0a-bb8c578623d7 LEGALITY=LEGAL PUUID=00000000-0000-0000-0000-000000000000 TYPE=SPARSE VOLTYPE=LEAF EOF [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# ll total 1025 -rw-rw----. 1 vdsm kvm 10737418240 Sep 22 18:15 9e4dc022-c450-4f85-89f5-233fa41c07d0 -rw-rw----. 1 vdsm kvm 1048576 Sep 22 18:15 9e4dc022-c450-4f85-89f5-233fa41c07d0.lease -rw-r--r--. 1 vdsm kvm 303 Sep 22 18:15 9e4dc022-c450-4f85-89f5-233fa41c07d0.meta [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# du -h ./9e4dc022-c450-4f85-89f5-233fa41c07d0 0 ./9e4dc022-c450-4f85-89f5-233fa41c07d0 [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# [root@olvms1 51dcbfae-1100-4e43-9e0a-bb8c578623d7]# -----Original Message----- From: users-bounces@ovirt.org <mailto:users-bounces@ovirt.org> <users-bounces@ovirt.org <mailto:users-bounces@ovirt.org> > On Behalf Of Tommy Sway Sent: Wednesday, September 22, 2021 6:07 PM To: 'Vojtech Juranek' <vjuranek@redhat.com <mailto:vjuranek@redhat.com> >; users@ovirt.org <mailto:users@ovirt.org> Subject: [ovirt-users] Re: about the vm disk type You mean if it's pre-allocated, it must be RAW, not Qcow2? The documentation only states that RAW must be pre-allocated, but it does not say that qCOW2 cannot use pre-allocation. -----Original Message----- From: Vojtech Juranek < <mailto:vjuranek@redhat.com> vjuranek@redhat.com> Sent: Wednesday, September 22, 2021 6:04 PM To: <mailto:users@ovirt.org> users@ovirt.org Cc: Tommy Sway < <mailto:sz_cuitao@163.com> sz_cuitao@163.com> Subject: Re: [ovirt-users] about the vm disk type On Wednesday, 22 September 2021 09:55:26 CEST Tommy Sway wrote:
When I create the VM's image disk, I am not asked to select the
following type of disk.
Actually you are, it's "Allocation Policy" drop down menu. Thin provisioned == qcow format Preallocated == raw
What is the default value ?
Thin provisioned, i.e. qcow.
Thanks.
QCOW2 Formatted Virtual Machine Storage
QCOW2 is a storage format for virtual disks. QCOW stands for QEMU
copy-on-write. The QCOW2 format decouples the physical storage layer
from the virtual layer by adding a mapping between logical and
physical
blocks.
Each logical block is mapped to its physical offset, which enables
storage over-commitment and virtual machine snapshots, where each QCOW
volume only represents changes made to an underlying virtual disk.
The initial mapping points all logical blocks to the offsets in the
backing file or volume. When a virtual machine writes data to a QCOW2
volume after a snapshot, the relevant block is read from the backing
volume, modified with the new information and written into a new
snapshot QCOW2 volume. Then the map is updated to point to the new place.
Raw
The raw storage format has a performance advantage over QCOW2 in that
no formatting is applied to virtual disks stored in the raw format.
Virtual machine data operations on virtual disks stored in raw format
require no additional work from hosts. When a virtual machine writes
data to a given offset in its virtual disk, the I/O is written to the
same offset on the backing file or logical volume.
Raw format requires that the entire space of the defined image be
preallocated unless using externally managed thin provisioned LUNs
from a storage array.
_______________________________________________ Users mailing list -- <mailto:users@ovirt.org> users@ovirt.org To unsubscribe send an email to <mailto:users-leave@ovirt.org> users-leave@ovirt.org Privacy Statement: <https://www.ovirt.org/privacy-policy.html> https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: <https://www.ovirt.org/community/about/community-guidelines/> https://www.ovirt.org/community/about/community-guidelines/ List Archives: <https://lists.ovirt.org/archives/list/users@ovirt.org/message/JGJX4VUOYVBG6AWPKWVMILXINNOFFO2V/> https://lists.ovirt.org/archives/list/users@ovirt.org/message/JGJX4VUOYVBG6A... _______________________________________________ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/JMXUYJXYWNHZ75...
Sorry for my misleading previous answer, I thought you are asking how to create pre/thin allocated disk. As for the format, you cannot choose it. As for the defaults, Benny already answered this.
I also have block storage on my environment. How do I observe the type of a vm image (LV)?
What do you exactly mean? Do you ask about image format (raw vs. cow)? If so, you can deduce it from Benny's answer, based on the facts on which domain is disk stored and if it's pre-allocated or not. If you are asking how to check it on the storage, you can check disk metadata or you can use directly qemu- img utility (qemu-img info /path/to/the/disk)
I just want know how to check the type. According to what you said, qemU-img info tool was used to query the result. On Block storage, theses are results: if preallocated, the storage format is RAW; If Thin mode, is QCOW2; If the VM is cloned from a template in preallocated mode, the disk consists of two files: the bottom back-end file is RAW, and the front end file is QCOW2. If the vm is cloned from a Thin template, I haven't had time to test this. According to the above classification, the performance of QCOW2 is worse than that of RAW format. Therefore, using preallocation mode for Block storage can not only remove interference at the file system level, but also achieve performance advantages in file types, thus achieving the best I/O effect. The last sentence was the result I really wanted, as I was running IO heavy systems on OLVM. Thank you! -----Original Message----- From: users-bounces@ovirt.org <users-bounces@ovirt.org> On Behalf Of Vojtech Juranek Sent: Wednesday, September 22, 2021 8:00 PM To: Tommy Sway <sz_cuitao@163.com> Cc: 'users' <users@ovirt.org> Subject: [ovirt-users] Re: about the vm disk type Sorry for my misleading previous answer, I thought you are asking how to create pre/thin allocated disk. As for the format, you cannot choose it. As for the defaults, Benny already answered this.
I also have block storage on my environment. How do I observe the type of a vm image (LV)?
What do you exactly mean? Do you ask about image format (raw vs. cow)? If so, you can deduce it from Benny's answer, based on the facts on which domain is disk stored and if it's pre-allocated or not. If you are asking how to check it on the storage, you can check disk metadata or you can use directly qemu- img utility (qemu-img info /path/to/the/disk)
According to what you said, qemU-img info tool was used to query the result. On Block storage, theses are results: if preallocated, the storage format is RAW;
correct
If Thin mode, is QCOW2;
correct
If the VM is cloned from a template in preallocated mode, the disk consists of two files: the bottom back-end file is RAW, and the front end file is QCOW2.
correct, second one is snapshot (not to modify template image) and snaphosts are always qcow2
If the vm is cloned from a Thin template, I haven't had time to test this.
both disks should be qcow2
According to the above classification, the performance of QCOW2 is worse than that of RAW format. Therefore, using preallocation mode for Block storage can not only remove interference at the file system level, but also achieve performance advantages in file types, thus achieving the best I/O effect.
The last sentence was the result I really wanted, as I was running IO heavy systems on OLVM.
if you want to use only raw file format, you should use preallocated disks on block storage (on file storage doesn't matter) and avoid snapshots, as snapshots are always qcow2 format
OK, thank you! -----Original Message----- From: Vojtech Juranek <vjuranek@redhat.com> Sent: Thursday, September 23, 2021 1:22 PM To: Tommy Sway <sz_cuitao@163.com> Cc: 'users' <users@ovirt.org> Subject: Re: [ovirt-users] Re: about the vm disk type
According to what you said, qemU-img info tool was used to query the result. On Block storage, theses are results: if preallocated, the storage format is RAW;
correct
If Thin mode, is QCOW2;
correct
If the VM is cloned from a template in preallocated mode, the disk consists of two files: the bottom back-end file is RAW, and the front end file is QCOW2.
correct, second one is snapshot (not to modify template image) and snaphosts are always qcow2
If the vm is cloned from a Thin template, I haven't had time to test this.
both disks should be qcow2
According to the above classification, the performance of QCOW2 is worse than that of RAW format. Therefore, using preallocation mode for Block storage can not only remove interference at the file system level, but also achieve performance advantages in file types, thus achieving the best I/O effect.
The last sentence was the result I really wanted, as I was running IO heavy systems on OLVM.
if you want to use only raw file format, you should use preallocated disks on block storage (on file storage doesn't matter) and avoid snapshots, as snapshots are always qcow2 format
participants (3)
-
Benny Zlotnik -
Tommy Sway -
Vojtech Juranek