You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Chiradeep Vittal <Ch...@citrix.com> on 2013/08/02 01:07:12 UTC
Re: vhd-util fails to open system vm template(.vhd) file, saying it
'appears invalid'
Check this thread
http://forums.citrix.com/thread.jspa?threadID=301226&start=0&tstart=0
On 7/30/13 3:46 AM, "Rajesh Battala" <ra...@citrix.com> wrote:
>Looks like the template disk got corrupted. Can you please reseed the
>system vm template and try.
>
>> -----Original Message-----
>> From: Yan Ke [mailto:yanke1@yonyou.com]
>> Sent: Tuesday, July 30, 2013 3:39 PM
>> To: users@cloudstack.apache.org
>> Subject: vhd-util fails to open system vm template(.vhd) file, saying it
>> 'appears invalid'
>>
>> Hello there,
>>
>> I'm working on setting up a basic network CloudStack 4.0.1 configuration
>> with XenServer 6.0.2 and encountered problem: after created zone, the
>> system vm won't start.
>> The management server log shows Exception like this was thrown:
>> WARN [xen.resource.CitrixResourceBase] (DirectAgent-322:) Catch
>>Exception
>> com.cloud.utils.exception.CloudRuntimeException on host:95cacdb9-a52d-
>> 4d22-8684-1310cca1a87d for template:
>> nfs://20.10.97.182/export/secondary/template/tmpl/1/1/ due to
>> com.cloud.utils.exception.CloudRuntimeException: can not create vdi in
>>sr
>> 3938e40f-99fe-cfc4-f729-00134eb32af0
>> com.cloud.utils.exception.CloudRuntimeException: can not create vdi in
>>sr
>> 3938e40f-99fe-cfc4-f729-00134eb32af0
>> at
>> com.cloud.hypervisor.xen.resource.CitrixResourceBase.copy_vhd_from_seco
>> ndarystorage(CitrixResourceBase.java:2672)
>> at
>>
>>com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResour
>>c
>> eBase.java:2694)
>> at
>>
>>com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(Citri
>>x
>> ResourceBase.java:481)
>> at
>> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(Xe
>> nServer56Resource.java:73)
>> at
>> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.j
>> ava:191)
>> at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>> at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>> at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.acc
>> ess$101(ScheduledThreadPoolExecutor.java:165)
>> at
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run
>> (ScheduledThreadPoolExecutor.java:266)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
>> a:1110)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
>> va:603)
>> at java.lang.Thread.run(Thread.java:679)
>>
>>
>> by stepping-into the code, I figured out this method
>> 'copy_vhd_from_secondarystorage(CitrixResourceBase.java:2672)' will
>>finally
>> invoke the 'copy_vhd_from_secondarystorage.sh' on XenServer host, so I
>> logged into the XenServer host, manually invoked the
>> 'copy_vhd_from_secondarystorage.sh' with same parameter from cloudstack,
>> which fails as follow:
>> [root@xenserver-modaxvnu /]#
>> /opt/xensource/bin/copy_vhd_from_secondarystorage.sh
>> 20.10.97.182:/export/secondary/template/tmpl/1/1/
>> 3938e40f-99fe-cfc4-f729-00134eb32af0
>> cloud-e6e25ca4-6a3f-4990-9e93-125b229cab0c
>> Syntax error: Unknown switch: -22MiB
>> For usage run: 'xe help'
>> 9#can not create vdi in sr 3938e40f-99fe-cfc4-f729-00134eb32af0
>>
>>
>> with a little effort on debugging the script, it shows that the error
>>occurred
>> at:
>> /opt/xensource/bin/vhd-util query -v -n /var/run/cloud_mount/c57e417b-
>> 4e9f-4c8b-8e67-087942422df3//8e62f48f-39e7-4543-9106-f2f12ca39946.vhd
>> + size='error opening
>> /var/run/cloud_mount/c57e417b-4e9f-4c8b-8e67-087942422df3//8e62f48f-
>> 39e7-4543-9106-f2f12ca39946.vhd:
>> -22'
>>
>> the 'vhd-util' failed to open the vm template file on secondary storage.
>>
>>
>> I then tried following command on the management server, which directly
>> invoke vhd-util and it shows:
>> [root@managementserver ~]#
>> /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util read -p
>> -n /export/secondary/template/tmpl/1/1/8e62f48f-39e7-4543-9106-
>> f2f12ca39946.vhd
>>
>> Failed to open
>> /export/secondary/template/tmpl/1/1/8e62f48f-39e7-4543-9106-
>> f2f12ca39946.vhd:
>> -22
>>
>> /export/secondary/template/tmpl/1/1/8e62f48f-39e7-4543-9106-
>> f2f12ca39946.vhd
>> appears invalid; dumping headers
>>
>> VHD Footer Summary:
>> -------------------
>> Cookie : QFI
>> Features : (0x00000000)
>> File format version : Major: 0, Minor: 0
>> Data offset : 16
>> Timestamp : Sat Jan 1 00:00:00 2000
>> Creator Application : '}'
>> Creator version : Major: 0, Minor: 0
>> Creator OS : Unknown!
>> Original disk size : 0 MB (196608 Bytes)
>> Current disk size : 0 MB (65536 Bytes)
>> Geometry : Cyl: 0, Hds: 0, Sctrs: 1
>> : = 0 MB (0 Bytes)
>> Disk type : None
>> Checksum : 0x0|0xfffffd8c (Bad!)
>> UUID : 00000000-0000-0000-0000-000000000000
>> Saved state : No
>> Hidden : 0
>>
>> VHD Header Summary:
>> -------------------
>> Cookie :
>> Data offset (unusd) : 0
>> Table offset : 0
>> Header version : 0x00000000
>> Max BAT size : 0
>> Block size : 0 (0 MB)
>> Parent name :
>> Parent UUID : 00000000-0000-0000-0000-000000000000
>> Parent timestamp : Sat Jan 1 00:00:00 2000
>> Checksum : 0x0|0xffffffff (Bad!)
>>
>> The (.vhd) file was generated by command from CloudStack installation
>> guide:
>>
>>/usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt
>> -m /mnt/ secondary -u
>> http://download.cloud.com/templates/acton/acton-systemvm-
>> 02062012.vhd.bz2
>> -h xenserver -F
>>
>> The file should be correct due to that it's generated under official
>> document's guidance , but 'vhd-util' says it 'appears invalid'.
>>
>> Anybody have got to solve the same problem? Or is there any mistake in
>>my
>> operation?
>>
>> More information:
>> a. I have assured that there is a 'vhd-util' in this directory:
>> '/usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util
>> '
>> b. I have assured that the primary/secondary storage both have no access
>> permission restrict.
>>
>>
>> And, thanks for your patient on reading this!
>>
>> Yours sincerely,
>> Yan Ke
>>
>