[one-users] onevm cancel for a persistent image via TM_ shared

[Hyun Woo Kim]

Dear Jaime,

Sorry for the delayed response.
(I returned from a log vacation.)

If using read link in order to check if the two(SRC and DST) are identical is intentional, I will need to think more on this issue.
I guess that as far as the original image file does not get corrupted by the link file, I think it is ok to us.
Anyway, let me think more on this issue.

Thanks for the response.

Hyunwoo Kim
FermiCloud Project

From: Jaime Melis <jmelis at opennebula.org<mailto:jmelis at opennebula.org>>
Date: Thursday, March 28, 2013 10:08 AM
To: Hyunwoo Kim <hyunwoo at fnal.gov<mailto:hyunwoo at fnal.gov>>
Cc: "users at lists.opennebula.org<mailto:users at lists.opennebula.org>" <users at lists.opennebula.org<mailto:users at lists.opennebula.org>>
Subject: Re: [one-users] onevm cancel for a persistent image via TM_ shared

Dear Hyun,

I don't quite understand what you mean. The step 3 doesn't do anything because it's the same file, so "it's already done". What would you have it do instead?

cheers,
Jaime


On Mon, Mar 18, 2013 at 4:17 PM, Hyun Woo Kim <hyunwoo at fnal.gov<mailto:hyunwoo at fnal.gov>> wrote:
Dear ON Developers,

Our ON configuration is a bit different from what ON manual assumes.
The following is my guess of how onevm cancel VM where this VM is from a persistent image and running in a host via shared transfer manager.

I believe the following two variables are assumed in ON standard deployment.
SRC=$IMAGE_REPOSITORY_PATH/
DST=$VM_DIR/vmid/images

In this case, onevm cancel will do

1. tm_mv.sh : mv $DST/disk.0 /var/log/one/vmid/disk.0
    Note here that $DST/disk.0 is actually a link to $IMAGE_REPOSITORY_PATH/original_file
2. tm_delete.sh : rm –f $DST
3. Image Driver will invoke var/remote/image/fs/mv to try to /var/log/one/vmid/disk.0 to the same image in IMAGE_REPOSITORY_PATH
    which will not happen because Image Drive will realize that these two are identical when running readlink command.

My guess is that, if this is true, this step "3" appears to be a bug.
In other words, in step "3", the mv should not be prevented because they have the same pathname.

Could ON developers check this?
(I might be wrong.)


Thank you.
Hyunwoo
FermiCloud Project



_______________________________________________
Users mailing list
Users at lists.opennebula.org<mailto:Users at lists.opennebula.org>
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org




--
Jaime Melis
Project Engineer
OpenNebula - The Open Source Toolkit for Cloud Computing
www.OpenNebula.org<http://www.OpenNebula.org> | jmelis at opennebula.org<mailto:jmelis at opennebula.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20130410/ec080802/attachment.htm>