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_ >
