Hi, I don't see how the links could have anything to do with it. Maybe it was some other ting and the restart solved it... Did anything else change? Are you using the same commands, from the same VM state? onevm delete, cancel and shutdown trigger different code in oned.
Regards -- Carlos Martín, MSc Project Engineer OpenNebula - The Open-source Solution for Data Center Virtualization www.OpenNebula.org | [email protected] | @OpenNebula<http://twitter.com/opennebula><[email protected]> On Wed, Jan 23, 2013 at 12:01 PM, Rolandas Naujikas < [email protected]> wrote: > Hi, > > I just tested with changed configuration. I put > DATASTORE_LOCATION=/real_path_**to_datastores and I don't see any > problems with images (references counting and in memory name cache) for the > moment. > > Do symlinks in virtualisation hosts to datastores location could lead to > that ? I saw that in very old messages in [email protected]. > > There are no text about symlinks in opennebula datastore documentation. > > Regards, Rolandas Naujikas > > P.S. My previous layout was (-> - means symlink): > > ~oneadmin/var/datastores/100 -> /lustre/one/datastores/100 > ~oneadmin/var/datastores/101 -> /lustre/one/datastores/101 > > in hosts and frontend. > > New layout is: > > ~oneadmin/var/datastores -> /lustre/one/datastores > DATASTORE_LOCATION=/lustre/**one/datastores > > where /lustre/one/datastores is real location of files. > > > On 2013-01-22 17:05, Carlos Martín Sánchez wrote: > >> Hi Rolandas, >> >> I've tried to reproduce the bug following your steps, but there must be >> something else that is triggering it. >> >> These are the exact commands I have executed, could you please check if >> I missed something? >> >> >> $ oneuser list >> ID NAME GROUP AUTH VMS MEMORY >> CPU >> 0 oneadmin oneadmin core - - >> - >> 1 serveradmin oneadmin server_c - - >> - >> 2 a oneadmin core - - >> - >> >> $ oneimage list >> ID USER GROUP NAME DATASTORE SIZE TYPE PER >> STAT RVMS >> 0 a oneadmin os default 1M OS No >> used 1 >> >> $ onevm list >> ID USER GROUP NAME STAT UCPU UMEM HOST >> TIME >> 0 a oneadmin one-0 runn 0 0K localhost >> 0d 00h00 >> >> $ onevm saveas 0 0 "img_saveas" >> >> $ onevm cancel 0 >> >> $ oneimage chown img_saveas oneadmin >> >> $ oneimage list >> ID USER GROUP NAME DATASTORE SIZE TYPE PER >> STAT RVMS >> 0 a oneadmin os default 1M OS No >> rdy 0 >> 1 oneadmin oneadmin img_saveas default 1M OS No >> rdy 0 >> >> $ oneimage delete img_saveas >> >> $ onetemplate instantiate 0 >> >> $ onevm list >> ID USER GROUP NAME STAT UCPU UMEM HOST >> TIME >> 1 a oneadmin one-1 runn 0 0K localhost >> 0d 00h00 >> >> $ onevm saveas 1 0 "img_saveas" >> >> $ onevm cancel 1 >> >> $ oneimage list >> ID USER GROUP NAME DATASTORE SIZE TYPE PER >> STAT RVMS >> 0 a oneadmin os default 1M OS No >> rdy 0 >> 2 a oneadmin img_saveas default 1M OS No >> rdy 0 >> >> $ oneimage chown img_saveas oneadmin >> >> $ oneimage list >> ID USER GROUP NAME DATASTORE SIZE TYPE PER >> STAT RVMS >> 0 a oneadmin os default 1M OS No >> rdy 0 >> 2 oneadmin oneadmin img_saveas default 1M OS No >> rdy 0 >> >> >> >> And the templates: >> >> >> $ onetemplate show 0 >> TEMPLATE 0 INFORMATION >> ID : 0 >> NAME : template-0 >> USER : a >> GROUP : oneadmin >> REGISTER TIME : 01/22 15:44:24 >> >> PERMISSIONS >> OWNER : um- >> GROUP : --- >> OTHER : --- >> >> TEMPLATE CONTENTS >> CPU="1" >> DISK=[ >> IMAGE="os" ] >> MEMORY="128" >> TEMPLATE_ID="0" >> >> >> $ oneimage show 0 >> IMAGE 0 INFORMATION >> ID : 0 >> NAME : os >> USER : a >> GROUP : oneadmin >> DATASTORE : default >> TYPE : OS >> REGISTER TIME : 01/22 15:44:12 >> PERSISTENT : No >> SOURCE : /var/lib/one/datastores/1/** >> 4be57b711606b657765d2c677fdf17**67 >> PATH : /etc/hosts >> SIZE : 1M >> STATE : rdy >> RUNNING_VMS : 0 >> >> PERMISSIONS >> OWNER : um- >> GROUP : --- >> OTHER : --- >> >> IMAGE TEMPLATE >> DEV_PREFIX="hd" >> >> Regards >> -- >> Carlos Martín, MSc >> Project Engineer >> OpenNebula - The Open-source Solution for Data Center Virtualization >> www.OpenNebula.org <http://www.OpenNebula.org> | [email protected] >> <mailto:[email protected]**> | @OpenNebula >> <http://twitter.com/opennebula**><mailto:cmartin@opennebula.**org<[email protected]> >> > >> >> >> >> On Tue, Jan 22, 2013 at 11:09 AM, Rolandas Naujikas >> <[email protected] >> <mailto:rolandas.naujikas@mif.**vu.lt<[email protected]>>> >> wrote: >> >> On 2013-01-22 09:58, Rolandas Naujikas wrote: >> >> Hi, >> >> I see that bug >> http://dev.opennebula.org/__**issues/1087<http://dev.opennebula.org/__issues/1087> >> >> >> <http://dev.opennebula.org/**issues/1087<http://dev.opennebula.org/issues/1087>> >> reappeared in >> 3.8.3. The sequence to repeat is: >> 1) create an image as save from VM (as an user in oneadmin group); >> 2) change owner to oneadmin; >> 3) delete image; >> 4) repeat (1) and (2) will fail saying "[ImageChown] USER [0] >> already >> owns IMAGE [N] with NAME XXX", where N - is id of already >> deleted image. >> Restart of one solves temporary problem. >> >> Also I saw several times that images were in use by nonexistent >> VM. >> onedb fsck will complain and correct that. >> >> >> At least I can confirm it with cancel action on VM. >> >> >> Regards, Rolandas Naujikas >> >> >> ______________________________**___________________ >> Users mailing list >> [email protected] >> <mailto:Users@lists.**opennebula.org<[email protected]> >> > >> >> http://lists.opennebula.org/__**listinfo.cgi/users-opennebula.**__org<http://lists.opennebula.org/__listinfo.cgi/users-opennebula.__org> >> >> <http://lists.opennebula.org/**listinfo.cgi/users-opennebula.**org<http://lists.opennebula.org/listinfo.cgi/users-opennebula.org> >> > >> >> >> >
_______________________________________________ Users mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
