What's the difference between type=CDROM and PERSISTENT images?

atodorov_storpool · September 2, 2016, 8:49pm

Hi,

Recently a customer managed to surprise our addon with an issue with several disks of type CDROM attached to single VM (obviously the second sentence of the CDROM description in the docs is obsolete at least for 4.14+ )

Ofter digging in the sources I’ve figured out that the the CDROM image type behave and should be threaten as always PERSISTENT image but with no VM/TEMPLATE/DISK/PERSISTENT=YES attribute set in the OpenNebula’s internal XML.

This leaded to situation that the VM is instantiated with the TM_MAD for the persistent images (tm/ln) but not handled properly in live-migrate and snapshot(?!?) scripts

Is it possible to sync it or rework the code to have both attributes set. In addition there is always PERSISTENT=n/a<->CLONE=YES and PERSISTENT=YES<->CLONE=NO mapping?

Or I am missing someting?

Kind Regards
Anton Todorov

Edit: sorry, saved too early…

ruben · September 7, 2016, 4:09pm

I’m not really sure I get the problem. CDROM disks will have CLONE=NO,
SAVE=NO, so it will invoke link operation rather than cp. Is not working
like that?

atodorov_storpool · September 7, 2016, 4:51pm

Hi Ruben,

Probably I’ve miss understood the PERSISTENT flag for the images. Should I use CLONE and SAVE attributes instead of PERSISTENT to detect is a image persistent one or not?

if you set the PERSISTENT flag on a CDROM image you will have CLONE=NO, SAVE=YES and PERSISTENT=YES. in both cases tm/ln is called for deployment.

What should be the proper check is the given VM disk PERSISTENT or NON-PERSISTENT for the migration scripts?

like:
CLONE=YES SAVE=*
on deploy - > clone the image (tm/cp is called)
on migrate -> thread as cloned
on terminate -> destroy the image

CLONE=NO SAVE=*
on deploy -> attach the image(tm/ln is called)
on migrate -> thread as persistent (but allow TYPE=CDROM to be attached if still in use)
on destroy -> detach from the nodes (but allow TYPE=CDROM to be attached if still in use)

This way my understanding is that the PERSISTENT flag is used only for the GUI needs?

Please excuse me if I am missing something…

Kind Regards,
Anton Todorov

ruben · September 7, 2016, 5:08pm

Yes you are right CLONE and SAVE attributes are the main flags used for the
TM logic. PERSISTENT is set into the DISK if the original Image is
persistent, this helps UI aspects…

CLONE controls what is done upon deployment, as you said CLONE=NO —>
tm/ln and CLONE=YES —> tm/cp

SAVE controls what happens upon VM termination (epilog) SAVE=YES -->
tm/mvds and SAVE=NO —> tm/delete . Note that delete is remove from system
DS, not the original image.

As a side note, there is a PERSISTENT_TYPE, if set to IMMUTABLE this means
READONLY=YES, CLONE=NO, SAVE=NO. This is basically to share RO data disks.

Feel free to ask more if is not clear

Cheers

atodorov_storpool · September 8, 2016, 8:36am

Thanks Ruben,

I’ll update the addon accordingly.

Kind Regards,
Anton Todorov

atodorov_storpool · September 8, 2016, 11:07am

Hi,

I’ve reworked the addon logic.
What I am observing:

CDROM image with checked PERSISTENT - tm/mvds is called on terminate
CDROM image without checked PERSISTENT - tm/delete is called on terminate.

What do you think about setting the CDROM type images to IMMUTABLE with no option to change?

So for now I’ve solved this with extra check for CLONE in tm/delete: if CLONE=YES then delete the image otherwise only detach with soft fail if it is still in use (attached to other VM as shared RO cdrom image)

I’ve found the PERSISTENT_TYPE in the sources but it is not well documented when/where to use it so our customer do not use it…

Kind Regards,
Anton Todorov

ruben · September 9, 2016, 10:42am

This is strange, look what is done with a disk is decided by this piece of
logic:

TransferManager.cc#L1247

As you can see it only considers SAVE=YES.

On the other hand CDROMs are treated as inmutable: CLONE = NO, SAVE = NO.

Anyway, removing only images that has been copied make sense (i.e. checking
for CLONE=YES) upon VM termination, for example:

github.com

OpenNebula/one/blob/master/src/tm_mad/ceph/delete#L119




#-------------------------------------------------------------------------------
# Get Image information
#-------------------------------------------------------------------------------


DISK_ID=$(echo "$DST_PATH" | $AWK -F. '{print $NF}')


# Reads the disk parameters -- taken from image datastore
unset i j XPATH_ELEMENTS
while IFS= read -r -d '' element; do
    XPATH_ELEMENTS[i++]="$element"
done < <(onevm show -x $VM_ID | $XPATH \
                    /VM/TEMPLATE/DISK[DISK_ID=$DISK_ID]/SOURCE \
                    /VM/TEMPLATE/DISK[DISK_ID=$DISK_ID]/CLONE \
                    /VM/TEMPLATE/DISK[DISK_ID=$DISK_ID]/CEPH_USER \
                    /VM/TEMPLATE/DISK[DISK_ID=$DISK_ID]/CEPH_KEY \
                    /VM/TEMPLATE/DISK[DISK_ID=$DISK_ID]/CEPH_CONF \
                    /VM/TEMPLATE/DISK[DISK_ID=$DISK_ID]/CEPH_TRASH \
                    /VM/TEMPLATE/DISK[DISK_ID=$DISK_ID]/POOL_NAME)


SRC="${XPATH_ELEMENTS[j++]}"

Cheers.

atodorov_storpool · September 9, 2016, 11:11am

Hi Ruben,

I can’t find any reference to PERSISTENT_TYPE besides src/image/Image.c. So it is possible to define an CDROM image without PERSISTENT_TYPE=IMMUTABLE set.

I think that with this patch it will follow the logic properly

https://github.com/OpenNebula/one/pull/111

Anyway, I’ve fixed it in the driver

Kind Regards,
Anton Todorov
Anton Todorov

Topic		Replies	Views
Persistent vs Non-Persistent Storage- here we go again Operations	1	186	August 12, 2024
Use cases for persistent & non-persisent Operations	2	2858	October 9, 2018
Question about non-persistent disk Product Support	2	3283	September 22, 2016
Losing data with persistent hard disks/images Product Support	2	694	February 26, 2018
Persistent VMs - why is disk image copied? (Opennebula 4 vs 5) Product Support	5	935	September 29, 2016

What's the difference between type=CDROM and PERSISTENT images?

Related topics