Bug #1029

Problem VMware persistent images

Added by Tino Vázquez over 9 years ago. Updated over 9 years ago.

Status:ClosedStart date:12/13/2011
Priority:NormalDue date:
Assignee:Tino Vázquez% Done:

0%

Category:Drivers - Auth
Target version:Release 3.2
Resolution:fixed Pull request:
Affected Versions:OpenNebula 3.2

Description

From Håkan Isaksson

-

I'm trying out opennebula-3.0.0 with the vmware-3.0.0 driver, and ESXi 4.1
it's mostly working well, but I have a problem with persistent images.

Starting a persistent vm works well, shutdown also works (the first time),
but the problem is that it tries to save the directory /src/clod/one/var/<vm>/disk.0 back to the image repository on shutdown,
and those files causes the save to fail the next time anyone instantiate and shutdown again on that image.

I have looked at /srv/cloud/one/var/remotes/image/fs/mv that is called when shutting down
and it seems to me that the script does not detect that the image
is symlinked because it's looking at the directory instead of the symlinked files.
(as in vmware-2.98 which could not even start a persistent image because of how ESXi treats linked directories).

I changed this part.

*)
log "Moving local image $SRC to the image repository"
if [ \( -L $SRC \) -a \( "`$READLINK $SRC`" = "$DST" \) ] ; then
log "Not moving files to image repo, they are the same"
else
exec_and_log "mv -f $SRC $DST" "Could not move $SRC to $DST"
fi
;;
esac

exec_and_log "chmod 0660 $DST"

to:

*)
log "Moving local image $SRC to the image repository"
if [ \( -L $SRC/disk.vmdk \) -a \( "`$READLINK -f $SRC/disk.vmdk`" = "$DST/disk.vmdk" \) ] ; then
log "Not moving files to image repo, they are the same"
else
exec_and_log "mv -f $SRC $DST" "Could not move $SRC to $DST"
fi
;;
esac

#exec_and_log "chmod 0660 $DST"
test -f "$DST" && exec_and_log "chmod 0660 $DST"
test -d "$DST" && exec_and_log "chmod 0770 $DST"

History

#1 Updated by Ruben S. Montero over 9 years ago

  • Target version changed from Release 3.4 to Release 3.2

#2 Updated by Ruben S. Montero over 9 years ago

  • Category set to Drivers - Auth
  • Status changed from New to Assigned
  • Assignee set to Tino Vázquez

#3 Updated by Ruben S. Montero over 9 years ago

  • Status changed from Assigned to Closed
  • Resolution set to fixed

#4 Updated by Ruben S. Montero over 9 years ago

this has been fixed by making a special link within the VMware disk folder. This way we keep the above logic but update the tm_vmware driver.

Anyway thanks for the feedback and the proposed solution :)

Also available in: Atom PDF