ovirt-4.4.3 Now default disk format for VM is RAW, if user want use QCOW2 he should check "Enable incremental backup checkbox" QCOW2 is required for support all features of KVM virtualization, also its provide more robust performance. Third and very important thing - if customer create RAW disk he cant easy convert them to QCOW2, and by this reason VM don't support incremental backup, until customer will perform manual disk convert. So, my suggestion - use QCOW as default as soon as possible, to reduce count vms with RAW disks and problem with incremental backup
(In reply to Yury.Panchenko from comment #0) > ovirt-4.4.3 > > Now default disk format for VM is RAW, if user want use QCOW2 he should > check "Enable incremental backup checkbox" Right > QCOW2 is required for support all features of KVM virtualization, also its > provide more robust performance. No, qcow2 give you more features, but raw is likely to give better performance and reliability. > Third and very important thing - if customer create RAW disk he cant easy > convert them to QCOW2, and by this reason VM don't support incremental > backup, until customer will perform manual disk convert. To enable backup for raw disk, user can create a snapshot. > So, my suggestion - use QCOW as default as soon as possible, to reduce count > vms with RAW disks and problem with incremental backup We want to keep the default configuration simple, and get best performance and reliability, so we kept the default of the system. We can introduce a system level option to allow incremental backup by default. In this case new vm will be created with "Enable incremental backup" by default. This is consistent with other features like wipe after delete, enabled globally if a user select non default value when installing engine. Note also that existing users already have raw disks, so even if we change the defaults backup application still have to deal with existing vms that cannot support incremental backup. I think this is more important since most users are likely to be existing users.
> We can introduce a system level option to allow incremental backup by > default. In this case new vm will be created with "Enable incremental backup" > by default. This is consistent with other features like wipe after delete, > enabled globally if a user select non default value when installing engine. My assumption is that most of the users/admins will not cancel the "Enable incremental backup" checkbox even if they don't plan to use it so the end result will be that the disks will be created in QCOW2 and the users will not get better performance. We should implement the solution for converting from RAW to COW and vise versa instead.
>> Now default disk format for VM is RAW, if user want use QCOW2 he should >> check "Enable incremental backup checkbox" >Right If we go forward - everyone want incremental backup. Its backup basis. This checkbox should be always checked (customer don't need to think about it). If customer want RAW he has another options like mount external LUN. > No, qcow2 give you more features, but raw is likely to give better performance > and reliability. Any additional layer cost some performance. Most modern hypervisors use own disk format. Usually performance test show nearly same speed as raw implementation. I don't think that qcow is exception. Select feature limited disk format as default - isn't optimal. > We want to keep the default configuration simple, and get best performance > and reliability, so we kept the default of the system. I agree that RAW was been optimal in previous time, but now you implemented backup API. Sometimes we need to make major changes. Now only QCOW allow use KVM in full functionality. I don't think that someone have plans use KVM in commercial case without backup. > To enable backup for raw disk, user can create a snapshot. Not suitable. RAW part always pass as full for every increment. Only disk convert will help. Also, snapshot have big impact on performance. > Note also that existing users already have raw disks, so even if we change > the defaults backup application still have to deal with existing vms that > cannot support incremental backup. Agree. I created this bug, to reduce count such users in future. if we change default in 4.4.4. - all users who started from that build get incremental backup without problems. Existing users should have easy option to enable support incremental backup. we need to raise priority of linked bug (which planned now only in 4.5)
Hello, Nir. > Not suitable. RAW part always pass as full for every increment. Only disk convert will help. This part isn't actual. Your workaround worked as expected
(In reply to Yury.Panchenko from comment #3) Adding a configuration for default format so users will be able to change the default format during installation or upgrade is very likely to happen. Change the default format needs more thinking and discussion. There are lot of good reasons to change the format.
*** Bug 1928756 has been marked as a duplicate of this bug. ***
I think that with the introduction of convert disk in RHV 4.4 SP1 this becomes less important We released cluster level 4.7 and we don't plan to introduce a new one (cluster level) soon - so changing the default is problematic in terms of API That means that even if we add such a configuration it would default to non-CBT and I doubt users would change that. I think the way forward with this one is: 1. To address the other issues we have so cloned disks with CBT enabled would have CBT enabled, and VMs that are provisioned from templates (and vice versa) would keep their CBT support and such. 2. To change the default selection in the UI so incremental backup would be selected What do you think?
Hello Arik, I think this will be enough > 2. To change the default selection in the UI so incremental backup would be selected Then any new vms will have enabled CBT by default, and users can back it up incrementally
(In reply to Yury.Panchenko from comment #13) > Then any new vms will have enabled CBT by default, and users can back it up > incrementally Not any new VM but VMs that are created from scratch (i.e., for which we create new disks) using the webadmin or that are provisioned from templates that have CBT enabled VMs that are provisioned from templates for which CBT is disabled or VMs that are created from scratch using the API would not be set with CBT enabled
(In reply to Arik from comment #12) > I think that with the introduction of convert disk in RHV 4.4 SP1 this > becomes less important True, but creating a disk in the wrong configuration, shutting down the vm (downtime) and converting it is not a good solution. > We released cluster level 4.7 and we don't plan to introduce a new one > (cluster level) soon - so changing the default is problematic in terms of API > That means that even if we add such a configuration it would default to > non-CBT and I doubt users would change that. Backup vendors can recommend this setting as part of the installation, so it will be useful even if we still don't enable incremental backup by default for new disks. > I think the way forward with this one is: > 1. To address the other issues we have so cloned disks with CBT enabled > would have CBT enabled, and VMs that are provisioned from templates (and > vice versa) would keep their CBT support and such. This is another issue, templates do not persist yet the incremental backup property. > 2. To change the default selection in the UI so incremental backup would be > selected > What do you think? The incremental backup default in the UI should be set by the new setting in engine config. So I think we have an agreement that we can enable backup=incremental by default in the UI and in the backend. A new engine config will help users to get the old behavior if they are not interested in backup. Practically this means new disks will be created in qcow2 format, so they can be backed up efficiently using incremental backup.
Shani, I merged the fix without checking how it would work on lower cluster levels that don't support incremental backup, did you check that? if not please do
(In reply to Arik from comment #16) > Shani, I merged the fix without checking how it would work on lower cluster > levels that don't support incremental backup, did you check that? if not > please do False alarm, that's ok
Verified on nightly build 4.5.1.3-654.af4ac851f145.33.el8ev When creating a new disk the incremental backup checkbox is checked by default as expected.
This bugzilla is included in oVirt 4.5.2 release, published on August 10th 2022. Since the problem described in this bug report should be resolved in oVirt 4.5.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.