Closed Franco-Sparrow closed 8 months ago
Hello team
May we follow-up on this?
Thanks in advance
Yes it should be reverted. Note that some VMs cannot use incremental, for example VMs with disk snapshots.
Maybe we should add a warning related to this
I will left this issue to log the error, i.e. VM cannot do INCREMENTAL
I will left this issue to log the error, i.e. VM cannot do INCREMENTAL
Thanks Mr. Montero
I will create new VM and will configure it first for FULL backup, and will try to revert it to INCREMENTAL backup. Will let you know the results, to conclude if previous werent able to revert backup type due to disk snapshot.
@rsmontero The config was successfully reverted.
On this specific VM 170
we dont know whats happening, you cant change the backup type or the checkbox for save the volatile disks from backup configuration, as it will reverted after update the config.
Show VM info:
onevm show 170
This is the VM info:
VIRTUAL MACHINE 170 INFORMATION
ID : 170
NAME : VM-TEST
USER : client1
GROUP : client1
STATE : ACTIVE
LCM_STATE : RUNNING
LOCK : None
RESCHED : No
HOST : DEV-N2-kvm
CLUSTER ID : 100
CLUSTER : KVM
START TIME : 11/10 17:04:33
END TIME : -
DEPLOY ID : 4a86031e-29ae-4284-b3ca-2ba939f9783a
VIRTUAL MACHINE MONITORING
CPU : 211.32
MEMORY : 64.1G
NETTX : 11.9G
NETRX : 14.9G
DISKRDBYTES : 5142174191616
DISKRDIOPS : 38485267
DISKWRBYTES : 4979423605248
DISKWRIOPS : 156115311
ID : 170
TIMESTAMP : 1700587751
PERMISSIONS
OWNER : um-
GROUP : ---
OTHER : ---
VM DISKS
ID DATASTORE TARGET IMAGE SIZE TYPE SAVE
2 images vdb VM-TEST-DATAWM S 855.6G/10 file NO
3 images vda VM-TEST-SYSTEM 66.1G/120 file NO
1 - hda CONTEXT 1M/- -
VM NICS
ID NETWORK BRIDGE IP MAC PCI_ID
0 client network 1 onebr6 X.Y.Z.12 02:00:ac:10:64:0c
SECURITY
NIC_ID NETWORK SECURITY_GROUPS
0 client1 network 1 0
SECURITY GROUP TYPE PROTOCOL NETWORK RANGE
ID NAME VNET START SIZE
0 default OUTBOUND ALL
0 default INBOUND ALL
VIRTUAL MACHINE HISTORY
SEQ UID REQ HOST ACTION DS START TIME PROLOG
0 12 3392 DEV-N2-k nic-attach 0 11/10 17:04:34 0d 00h01m 0h00m02s
1 12 1840 DEV-N2-k disk-attac 0 11/10 17:05:45 0d 00h09m 0h00m00s
2 12 1792 DEV-N2-k nic-detach 0 11/10 17:14:47 0d 01h48m 0h00m00s
3 12 176 DEV-N2-k nic-attach 0 11/10 19:02:49 0d 00h01m 0h00m00s
4 12 1536 DEV-N2-k poweroff 0 11/10 19:04:46 0d 22h36m 0h00m00s
5 12 8640 DEV-N2-k disk-detac 0 11/11 17:40:47 1d 02h16m 0h00m00s
6 12 880 DEV-N2-k disk-attac 0 11/12 19:56:57 0d 00h00m 0h00m00s
7 - - DEV-N2-k poweroff-h 0 11/12 19:57:24 0d 00h05m 0h00m00s
8 12 8704 DEV-N2-k poweroff-h 0 11/12 20:02:44 0d 01h02m 0h00m00s
9 12 3760 DEV-N2-k poweroff-h 0 11/12 21:05:32 0d 00h11m 0h00m00s
10 - - DEV-N2-k monitor 0 11/12 21:17:24 0d 20h37m 0h00m00s
11 12 2320 DEV-N2-k backup 0 11/13 17:54:50 0d 09h04m 0h00m00s
12 12 1920 DEV-N2-k backup 0 11/14 02:59:09 0d 00h04m 0h00m00s
13 0 6640 DEV-N2-k backup 0 11/14 03:03:59 3d 09h56m 0h00m00s
14 - - DEV-N2-k none 0 11/17 13:00:03 3d 20h29m 0h00m00s
SCHEDULED ACTIONS
ID ACTION ARGS SCHEDULED REPEAT END STATUS
0 backup 100 11/22 06:00 Weekly 3,6 None Next in 20.51 hours
BACKUP CONFIGURATION
BACKUP_VOLATILE="YES"
FS_FREEZE="AGENT"
INCREMENTAL_BACKUP_ID="-1"
KEEP_LAST="7"
LAST_INCREMENT_ID="-1"
MODE="FULL"
VM BACKUPS
IMAGE IDS: 77,97
USER TEMPLATE
HOT_RESIZE=[
CPU_HOT_ADD_ENABLED="NO",
MEMORY_HOT_ADD_ENABLED="NO" ]
LOGO="images/logos/windows8.png"
MEMORY_UNIT_COST="MB"
VIRTUAL MACHINE TEMPLATE
AUTOMATIC_DS_REQUIREMENTS="(\"CLUSTERS/ID\" @> 0 | \"CLUSTERS/ID\" @> 100)"
AUTOMATIC_NIC_REQUIREMENTS="(\"CLUSTERS/ID\" @> 0 | \"CLUSTERS/ID\" @> 100)"
AUTOMATIC_REQUIREMENTS="(CLUSTER_ID = 0 | CLUSTER_ID = 100) & !(PUBLIC_CLOUD = YES) & !(PIN_POLICY = PINNED)"
CONTEXT=[
DISK_ID="1",
ETH0_DNS="8.8.8.8",
ETH0_EXTERNAL="",
ETH0_GATEWAY="X.Y.Z.111",
ETH0_IP="X.Y.Z.12",
ETH0_IP6="",
ETH0_IP6_GATEWAY="",
ETH0_IP6_METHOD="",
ETH0_IP6_METRIC="",
ETH0_IP6_PREFIX_LENGTH="",
ETH0_IP6_ULA="",
ETH0_MAC="02:00:ac:10:64:0c",
ETH0_MASK="255.255.255.0",
ETH0_METHOD="",
ETH0_METRIC="",
ETH0_MTU="",
ETH0_NETWORK="X.Y.Z.0",
ETH0_SEARCH_DOMAIN="",
ETH0_VLAN_ID="2718",
ETH0_VROUTER_IP="",
ETH0_VROUTER_IP6="",
ETH0_VROUTER_MANAGEMENT="",
NETWORK="YES",
SSH_PUBLIC_KEY="",
TARGET="hda" ]
CPU="2"
GRAPHICS=[
LISTEN="0.0.0.0",
PORT="6070",
TYPE="VNC" ]
MEMORY="65536"
MEMORY_RESIZE_MODE="BALLOONING"
OS=[
UUID="4a86031e-29ae-4284-b3ca-2ba939f9783a" ]
TEMPLATE_ID="39"
TM_MAD_SYSTEM="shared"
VCPU="8"
VMID="170"
Do you see anything strange here Sir? The VM was created from a qcow2 image imported to the OpenNebula. It has a data disk and the OS disk. It was first configured for FULL backup and now cant be reverted to INCREMENTAL backup.
Just in case the keyword is MODE="INCREMENT" not INCREMENTAL...
Yes, sorry for that. I have tested Updating the config from the cli, specifying that key word too (INCREMENT). The VM config just return to FULL and the VM doesnt have any snapshot on its disks.
El mié, 22 nov 2023 9:53 a. m., Ruben S. Montero @.***> escribió:
Just in case the keyword is MODE="INCREMENT" not INCREMENTAL...
— Reply to this email directly, view it on GitHub https://github.com/OpenNebula/one/issues/6400#issuecomment-1822921443, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANRJPNYF2NDOO7D2M7JLNH3YFYGXHAVCNFSM6AAAAAA7LXRGXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRSHEZDCNBUGM . You are receiving this because you authored the thread.Message ID: @.***>
Also all disks needs to be qcow2
For the reference:
Check on disks for increment is done here:
Also all disks needs to be qcow2
Yes Sir, all the VM disks are qcow2 disks and none of them have snapshot disks. The problem was resolved recreating the VM from the begining.
It would be nice the warning for trying to configure the INCREMENT backup on a VM that doesnt have qcow2 disks or have snapshots disks :).
Thanks in advance Mr. Montero.
Hi @rsmontero , we find a problem in our cluster, We didn't have the FORMAT property in the disk template. That's why we can't use the incremental backups in old vms imported from the 5.12 version.
Do you have any suggestion? Can I suggest to use the DRIVER property instead of FORMAT.
Also is the onedb update-body vm --id <vm_id>
the only way to fix the problem?
I was able to change to INCREMENTAL after adding FORMAT property to the body of the vm template.
This is our VM template (part of):
...
CPU = "1"
DISK = [
ALLOW_ORPHANS = "NO",
CLONE = "YES",
CLONE_TARGET = "SYSTEM",
CLUSTER_ID = "0,100",
DATASTORE = "images",
DATASTORE_ID = "1",
DEV_PREFIX = "vd",
DISK_ID = "0",
DISK_SNAPSHOT_TOTAL_SIZE = "0",
DISK_TYPE = "FILE",
DRIVER = "qcow2",
IMAGE = "windows2019-Sep2020",
IMAGE_ID = "2",
IMAGE_STATE = "2",
LN_TARGET = "NONE",
ORIGINAL_SIZE = "51200",
READONLY = "NO",
SAVE = "NO",
SIZE = "102400",
SOURCE = "/var/lib/one//datastores/1/bb52083cfd52218c3957ce830b1aaf43",
TARGET = "vda",
TM_MAD = "shared",
TYPE = "FILE" ]
FEATURES = [
...
Description Once configured the backups for a given VM, and specified to FULL backup, this configuration cannot be reverted either via Sunstone or CLI (
onevm updateconf VM_ID
). It allways get back to first configuration (on this case, the Full backup).To Reproduce Configure FULL backup for a given VM via Suntone and after apply configuration, try to reconfigure it and select this time the INCREMENTAL backups.
Expected behavior The VM backup type should have changed to the new one.
Details