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