OpenNebula / one

The open source Cloud & Edge Computing Platform bringing real freedom to your Enterprise Cloud 🚀
http://opennebula.io
Apache License 2.0
1.23k stars 479 forks source link

VM configured for FULL backup on Sunstone cant be changed to INCREMENTAL backup #6400

Closed Franco-Sparrow closed 8 months ago

Franco-Sparrow commented 11 months ago

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

Franco-Sparrow commented 10 months ago

Hello team

May we follow-up on this?

Thanks in advance

rsmontero commented 10 months ago

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

rsmontero commented 10 months ago

I will left this issue to log the error, i.e. VM cannot do INCREMENTAL

Franco-Sparrow commented 10 months ago

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.

Franco-Sparrow commented 10 months ago

@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.

rsmontero commented 10 months ago

Just in case the keyword is MODE="INCREMENT" not INCREMENTAL...

Franco-Sparrow commented 10 months ago

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: @.***>

rsmontero commented 10 months ago

Also all disks needs to be qcow2

rsmontero commented 10 months ago

For the reference:

Check on disks for increment is done here:

Franco-Sparrow commented 10 months ago

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.

nachowork90 commented 6 months ago

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.

https://github.com/OpenNebula/one/blob/57efabf2d59051788be3aec67bcd8bce36d95566/src/vm/VirtualMachineDisk.cc#L1553-L1577

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 = [
...