Bug 1908075 - Unable to change VM power state during backup
Summary: Unable to change VM power state during backup
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backup-Restore.VMs
Version: 4.4.3.12
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: bugs@ovirt.org
QA Contact: meital avital
bugs@ovirt.org
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-12-15 19:45 UTC by Yury.Panchenko
Modified: 2021-11-12 09:41 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-08-29 17:55:30 UTC
oVirt Team: Storage
Embargoed:


Attachments (Terms of Use)

Description Yury.Panchenko 2020-12-15 19:45:34 UTC
Description of problem:
This is more conceptual problem. 
When backup is working, user can’t change power state of backed vm. And because backup can take a long time, in many cases users will need reboot vm or poweroff them, but all that actions is locked from management UI.

Current workarounds are trigger this action inside vm, but that is unclear.
Also, if user poweroff vm, backup will be failed.

I think vm backup process should not affect changing vm power state. If vm is switched off QEMU should continue keep checkpoint and backup should continue working.

Version-Release number of selected component (if applicable):
Ovirt  4.4.3.12-0.1.el8ev
QEMU 5.1

How reproducible:
Just poweroff vm when backup is running

Comment 1 Eyal Shenitzky 2020-12-23 06:55:46 UTC
Hi Yury,

As we discussed, in order to support VM state changes during a backup operation the QEMU process must be present.
When power-off the VM, QEMU process is terminated and there is no way to track the changed blocks and transfer the changed data.

Currently, QEMU and Libvirt don't support the option of keeping the VM in a state that will allow waiting for the backup to end.
In RHV, we do everything we can to prevent that state from happening, but we can't control the guest, so if the VM will be powered off 
during a backup, the expected result should be a termination of the backup and a proper failure message should be sent (bug 1892672).

Comment 2 Yury.Panchenko 2021-01-04 13:33:46 UTC
Hello, Eyal.
> As we discussed, in order to support VM state changes during a backup operation the QEMU process must be present.
> When power-off the VM, QEMU process is terminated and there is no way to track the changed blocks and transfer the changed data.
Yes, limitation of current algorithm. Probably if we split change tracking mechanism in separate process, we can remove dependency on power state. You are considering it?

> Currently, QEMU and Libvirt don't support the option of keeping the VM in a state that will allow waiting for the backup to end.
> In RHV, we do everything we can to prevent that state from happening, but we can't control the guest, so if the VM will be powered off 
> during a backup, the expected result should be a termination of the backup and a proper failure message should be sent (bug 1892672).

Usually backup process controlled by system administrators, and vm users doesn't know anything about when its vms are backuped up. So it means that customers can cause backup failure by poweroff vms, and SA need to be ask user to power on vm back. 

I really understand that in current implementation that bug not so easy to fix, but i want to be sure that you have plans to fix that, and some ETA when.
Thanks.

Comment 3 Nir Soffer 2021-01-04 19:06:07 UTC
When offline backup will be available, power off during backup will
abort the backup, but the backup application can recover by starting
an offline backup, so the process can be transparent to users.

For power state changes via RHV API/UI, we try to avoid state changes
during backup, but we must give user the option to abort a backup.
Backup application should be prepared to recover from such failures.

Supporting power state changes during backup (online or offline) may
be possible when qemu storage daemon will be available. We may be able
to start qemu storage daemon with the disks, and perform the backup
using qemu storage daemon, so starting and stopping the vm will not
affect backups.

This may also be the way incremental backup will be supported in 
openshift virtualization. Supporting this in RHV will make it easier
to migrate from RHV to openshift virtualization.

We don't plan to support this yet, but we will consider this in the
future.

Comment 5 Eyal Shenitzky 2021-08-29 17:55:30 UTC
(In reply to Nir Soffer from comment #3)
> When offline backup will be available, power off during backup will
> abort the backup, but the backup application can recover by starting
> an offline backup, so the process can be transparent to users.
> 
> For power state changes via RHV API/UI, we try to avoid state changes
> during backup, but we must give the user the option to abort a backup.
> Backup application should be prepared to recover from such failures.
> 
> Supporting power state changes during backup (online or offline) may
> be possible when qemu storage daemon will be available. We may be able
> to start qemu storage daemon with the disks, and perform the backup
> using qemu storage daemon, so starting and stopping the vm will not
> affect backups.
> 
> This may also be the way incremental backup will be supported in 
> openshift virtualization. Supporting this in RHV will make it easier
> to migrate from RHV to openshift virtualization.
> 
> We don't plan to support this yet, but we will consider this in the
> future.

There are no plans to support VM incremental backup during VM state changes at this point.
The behavior will be according to the description given by Nir in comment#3.

It can be transparent to the user if a Live backup failed by initiating a cold backup.

Closing this RFE.


Note You need to log in before you can comment on or make changes to this bug.