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