Inherit disk snapshots

Community Support
1

When a disk snapshot is created, it is inherited by the parent.

“This is now implemented for 5.4” - https://dev.opennebula.org/issues/4885
But now I have ONe 5.4 with enabled ALLOW_ORPHANS for Ceph DS and it isn`t working.

TM_MAD_CONF = [
    NAME = "ceph", LN_TARGET = "NONE", CLONE_TARGET = "SELF", SHARED = "YES",
    DS_MIGRATE = "NO", DRIVER = "raw", ALLOW_ORPHANS="yes"
]

Versions of the related components and OS (frontend, hypervisors, VMs):
CentOS 7, ceph version 10.2.10 (5dc1e4c05cb68dbf62ae6fce3f0700e4654fdbbe), One 5.4.1

Steps to reproduce:

Current results:

Expected results:
Snapshots can live without parents

2

Hi Roman,

As it is not clear I would speculate that you are working with upgraded OpenNebula.

You should check the following:

  • Despite TM_MAD_CONF you must have ALLOW_ORPHANS = YES in each datastore that have ceph as TM_MAD. This will enable the option for the newly created VMs.

  • On the current VMs dump the metadata XML using onevm show $VMID --xml and check the /VM/SNAPSHOTS/ALLOW_ORPHANS value should be YES. If it is NO you could alter the VM record to change it to YES and fix the snapshots relations. Here is a short example how you could do this (Please note that you should backup the database to revert if anything went wrong):

# For example to change ALLOW_ORPHANS=YES on DISK_ID=0 of VM_ID=42
# you should repeat for each disk in the VM metadata
onedb change-body vm --id 42 '/VM/SNAPSHOTS[DISK_ID=0]/ALLOW_ORPHANS' -- "YES"

Also you must flatten the snapshots tree by changing the snapshots PARENT to -1:

# change _PARENT=-1_ for snapshot 0 and 1 of disk 0 on VM 42
# you should repeat the step for all disk snapshots
onedb change-body vm --id 42 '/VM/SNAPSHOTS[DISK_ID=0]/SNAPSHOT[ID=0]/PARENT' -- "-1"
onedb change-body vm --id 42 '/VM/SNAPSHOTS[DISK_ID=0]/SNAPSHOT[ID=1]/PARENT' -- "-1"

Now if you refresh(reload?) the interface in sunstone you should b able to delete each snapshot.

Hope this helps.

Best Regards,
Anton Todorov

3

Thank you.
For a new VMs that`s ok.
But for current VMs there are problems.

onedb change-body vm --id 23 '/VM/SNAPSHOTS[DISK_ID=0]/SNAPSHOT[ID=0]/PARENT' -- "-1"
onedb change-body vm --id 23 '/VM/SNAPSHOTS[DISK_ID=0]/SNAPSHOT[ID=1]/PARENT' -- "-1"

After flatten snapshots i have two active snapshots and can`t delete them.
08

4

Hi Roman,

At first glance it looks like there is something cached in the sunstone and/or your browser. It is very basic tree representation schema - each snapshot has pointer to it’s parent with root one set to ‘-1’. To verify the VM’s metadata can you provide the VM’s XML onevm show 23 --xml to see is there something fishy. Feel free to edit any sensitive data before posting it.

Best Regards,
Anton Todorov

5 
    <CPU><![CDATA[1]]></CPU>
    <DISK>
      <CEPH_HOST><![CDATA[IP_1,IP_2,IP_3]]></CEPH_HOST>
      <CEPH_SECRET><![CDATA[ceph_secret]]></CEPH_SECRET>
      <CEPH_USER><![CDATA[libvirt]]></CEPH_USER>
      <CLONE><![CDATA[YES]]></CLONE>
      <CLONE_TARGET><![CDATA[SELF]]></CLONE_TARGET>
      <CLUSTER_ID><![CDATA[0]]></CLUSTER_ID>
      <DATASTORE><![CDATA[vCloudDatastore]]></DATASTORE>
      <DATASTORE_ID><![CDATA[100]]></DATASTORE_ID>
      <DEV_PREFIX><![CDATA[vd]]></DEV_PREFIX>
      <DISK_ID><![CDATA[0]]></DISK_ID>
      <DISK_SNAPSHOT_TOTAL_SIZE><![CDATA[182880]]></DISK_SNAPSHOT_TOTAL_SIZE>
      <DISK_TYPE><![CDATA[RBD]]></DISK_TYPE>
      <DRIVER><![CDATA[raw]]></DRIVER>
      <IMAGE><![CDATA[C4218_CLEINTNAME]]></IMAGE>
      <IMAGE_ID><![CDATA[16]]></IMAGE_ID>
      <IMAGE_STATE><![CDATA[2]]></IMAGE_STATE>
      <IMAGE_UNAME><![CDATA[oneadmin]]></IMAGE_UNAME>
      <LN_TARGET><![CDATA[NONE]]></LN_TARGET>
      <POOL_NAME><![CDATA[one]]></POOL_NAME>
      <READONLY><![CDATA[NO]]></READONLY>
      <SAVE><![CDATA[NO]]></SAVE>
      <SIZE><![CDATA[91440]]></SIZE>
      <SOURCE><![CDATA[one/one-16]]></SOURCE>
      <TARGET><![CDATA[vda]]></TARGET>
      <TM_MAD><![CDATA[ceph]]></TM_MAD>
      <TYPE><![CDATA[RBD]]></TYPE>
    </DISK>

  <SNAPSHOTS>
    <DISK_ID><![CDATA[0]]></DISK_ID>
    <SNAPSHOT>
      <CHILDREN><![CDATA[1]]></CHILDREN>
      <DATE><![CDATA[1506341357]]></DATE>
      <ID><![CDATA[0]]></ID>
      <NAME><![CDATA[25092017]]></NAME>
      <PARENT><![CDATA[-1]]></PARENT>
      <SIZE><![CDATA[91440]]></SIZE>
    </SNAPSHOT>
    <SNAPSHOT>
      <ACTIVE><![CDATA[YES]]></ACTIVE>
      <DATE><![CDATA[1508934981]]></DATE>
      <ID><![CDATA[1]]></ID>
      <NAME><![CDATA[25102017]]></NAME>
      <PARENT><![CDATA[-1]]></PARENT>
      <SIZE><![CDATA[91440]]></SIZE>
    </SNAPSHOT>
  </SNAPSHOTS>
6

Hi Roman,

the DISK and SNAPSHOTS entries has no ALLOW_ORPHANS=yes attribute, and the first snapshot (with id=0) has childrens attribute… Unfortunately onedb change-body has no function to add entries yet (F#5448, F#5532). So I’ve scratched a quick extension for onedb patch tool to fix the VM’s metadata table the hard way…

How to use:

  1. download the above gist as file named allow_orphans.rb
  2. Stop the opennebula service
  3. Run onedb patch <database related argumets> allow-orphans.rb which will do the following:
    add ALLOW_ORPHANS=YES for each DISK entry
    add ALLOW_ORPHANS=YES for each set of disk SNAPSHOTS
    delete the CHILDREN element in each disk SNAPSHOT entry
    update PARENT element to ‘-1’ in each disk SNAPSHOT entry
  4. Start the opennebula service
  5. Restart opennebula-sunstone service

Use onedb patch --help for more information how set DB connection argumets

The tool will create a backup of the database, but to be on the safe side please do your own backup of the database too in case anything goes wrong.

If this doesn’t help I am out of ideas …

Best Regards,
Anton Todorov

1 Like
7

Thank you. It works.

 VM_ID:23 state:3 lcm_state:3
   DISKS DISK_ID:0 :: <ALLOW_ORPHANS><![CDATA[YES]]></ALLOW_ORPHANS>
   SNAPS DISK_ID:0 :: <ALLOW_ORPHANS><![CDATA[YES]]></ALLOW_ORPHANS>
        SNAPSHOT_ID:0 :: <PARENT><![CDATA[-1]]></PARENT>
        SNAPSHOT_ID:1 :: <PARENT><![CDATA[-1]]></PARENT>