Hi Kirk and Travis, Thanks for your fast answer and reply. The problem was the one Kirk mention, NFFSSR.py have been replace by an hotfix, we recently apply a xenserver hotfix and since then we had problem creating templates. Pretty much in the same time we add a new zone so I wasn't sure which event cause the issue which is why I did not say it in the first email.
doe anyone know if there is a doc reference of all scripts replace on xenserver by cloudstack? if it is not the only script. That said, the only doc I've found regarding updating hypervisors is http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Admin_Guide/maintain-hypervisors-on-hosts.html which contain an outdated link. Thanks again ! Pierre-Luc Dion Responsable technique - infrastructure | Technical lead - infrastructure 514-447-3456, 1101 - - -* CloudOps *420 rue Guy Montréal QC H3J 1S6 www.cloudops.com @CloudOps_ On Thu, Oct 3, 2013 at 4:15 PM, Kirk Kosinski <kirkkosin...@gmail.com>wrote: > Did you patch the hosts recently? That is the likely cause. The > patched NFSSR.py that CloudStack copies to XS hosts can be overwritten > by some patches. Without the patched NFSSR.py, when secondary storage > is mounted it reverts to the default XenServer behavior of including an > extra directory named after the SR UUID. > > One solution is to copy the correct NFSSR.py manually from the > management server to /opt/xensource/sm/NFSSR.py on every XS host. There > will be several versions of the script in > /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/ on the > management server, and you can check the MD5 checksums beforehand to > confirm it is the problem. > > Another solution is to force CloudStack to setup the host again, which > includes copying NFSSR.py. To do this, unmanage the cluster in > Cloudstack, clear the "tags" parameter for every host in the cluster (xe > host-list, xe host-param-clear uuid=<uuid> param-name=tags), re-manage > the cluster, and wait a few minutes. > > Best regards, > Kirk > > On 10/03/2013 12:51 PM, Pierre-Luc Dion wrote: > > Hi all, > > > > We are currently using Cloudstack 4.1.0 managing XenServer 6.0.2 servers. > > > > > > Since recently, I don't know what cause this to appear on our system but > > went we create a template from a Instance the template (.vhd) is upload > on > > on the secondary storage (NFS) but in a subdirectory ex: > > > > from the Storage VM: > > /mnt/SecStorage/7f6f1f2d-2d6f-3ec6-a25e-fb25f2704167/template/tmpl/3/246 > > root@s-184-VM:~# ls -l > > total 8 > > drwxr-xr-x 2 4294967294 4294967294 4096 Oct 3 19:35 > > 02ee28f2-0c02-f936-3ca3-099cfe3f3a20 > > -rw-rw-rw- 1 4294967294 4294967294 314 Oct 3 19:36 template.properties > > > > root@s-184-VM:~# ls 02ee28f2-0c02-f936-3ca3-099cfe3f3a20/ > > fe2fa941-3030-412d-8c35-b0e80a2e7e09.vhd > > > > > > So, when we create a new Instance from the template, the Instance > creation > > fail with the following error in the management-server.log: > > > > 2013-10-03 15:48:01,190 WARN [xen.resource.CitrixResourceBase] > > (DirectAgent-255:null) Catch Exception > > com.cloud.utils.exception.CloudRuntimeException on > > host:9a02ac57-bc92-43af-b50a-f5ba2d0fd806 for template: nfs:// > > > 172.24.1.120/data/secondary/template/tmpl/3/246/fe2fa941-3030-412d-8c35-b0e80a2e7e09.vhddue > > to com.cloud.utils.exception.CloudRuntimeException: can not create vdi > > in sr 451078ee-d335-bdb0-c41c-cd86524be3ea > > > > if I move the VHD file in the 246 folder, it works ! > > > > Does anyone have this problem too or have an idea of where it would come > > from ? > > > > Thanks ! > > > > > > Pierre-Luc Dion > > Responsable technique - infrastructure | Technical lead - infrastructure > > - - -* > > CloudOps > > *www.cloudops.com > > @CloudOps_ > > >
