Vladimir Ostrovsky created CLOUDSTACK-360:
---------------------------------------------
Summary: System VM template isn't copied from Secondary Storage to
XenServer's local SR
Key: CLOUDSTACK-360
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-360
Project: CloudStack
Issue Type: Bug
Components: Install and Setup, XenServer
Affects Versions: pre-4.0.0
Environment: CloudStack: 2.2.14
Hypervisor: XenServer 5.6 with SP2 and with CloudStack Support Pack
Reporter: Vladimir Ostrovsky
I've a XenServer with local storage repository. When the XenServer is added to
CloudStack's cluster, the SR is automatically recognized as Primary Storage for
the cluster.
The Global Settings are to to use local storage:
system.vm.use.local.storage = true
use.local.storage = true
The problem is that when CloudStack tries to deploy its System VMs, it tries to
copy the template from the NFS-based Secondary Storage to this Primary Storage
and fails.
The following appears in the /var/log/cloud/management/management-server.log
file:
----------------------------
2012-10-16 12:20:50,672 DEBUG [cloud.storage.StorageManagerImpl]
(consoleproxy-1:null) Checking if we need to prepare 1 volumes for
VM[ConsoleProxy|v-2-VM]
2012-10-16 12:20:50,676 DEBUG [cloud.storage.StorageManagerImpl]
(consoleproxy-1:null) Creating volume: Vol[2|vm=2|ROOT]
2012-10-16 12:20:50,676 DEBUG [cloud.storage.StorageManagerImpl]
(consoleproxy-1:null) Trying to create in Pool[200|LVM]
2012-10-16 12:20:51,317 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-24:null) failed to dd
/var/run/cloud_mount/5e9f3a2d-1d7f-4ed8-a0d6-74b1b574aeac//08cee70c-6bd0-4177-8677-7c45db9f7b77.vhd
to
/dev/VG_XenStorage-7088ed1b-5a5b-fd89-b223-500cfe5b6498/VHD-abdac78f-3b3e-4cb9-bde7-03603d484f2f
2012-10-16 12:20:51,339 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-24:null) Catch Exception
com.cloud.utils.exception.CloudRuntimeException on
host:d358cf70-ac85-4192-8f16-fba3fbe28111 for template:
nfs://10.46.26.3/SecStorageBasicZone/template/tmpl/1/1/ due to
com.cloud.utils.exception.CloudRuntimeException: failed to dd
/var/run/cloud_mount/5e9f3a2d-1d7f-4ed8-a0d6-74b1b574aeac//08cee70c-6bd0-4177-8677-7c45db9f7b77.vhd
to
/dev/VG_XenStorage-7088ed1b-5a5b-fd89-b223-500cfe5b6498/VHD-abdac78f-3b3e-4cb9-bde7-03603d484f2f
com.cloud.utils.exception.CloudRuntimeException: failed to dd
/var/run/cloud_mount/5e9f3a2d-1d7f-4ed8-a0d6-74b1b574aeac//08cee70c-6bd0-4177-8677-7c45db9f7b77.vhd
to
/dev/VG_XenStorage-7088ed1b-5a5b-fd89-b223-500cfe5b6498/VHD-abdac78f-3b3e-4cb9-bde7-03603d484f2f
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.copy_vhd_from_secondarystorage(CitrixResourceBase.java:2293)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2315)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:459)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:75)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:192)
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.access$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
----------------------------
At the same time, this appears in the /var/log/messages file on the XenServer:
----------------------------
Oct 16 10:44:00 Xen-46-26-a mountd[9250]: authenticated mount request from
10.46.26.2:773 for /SecStorageAdvancedZone/template/tmpl/1/1
(/SecStorageAdvancedZone)
Oct 16 10:44:01 Xen-46-26-a fe: 19689 (/opt/xensource/sm/LVMSR
<methodCall><methodName>vdi_create</methodName><param...) exitted with code 0
Oct 16 10:44:02 Xen-46-26-a fe: 19669 (/etc/xapi.d/plugins/vmopspremium
<methodCall><methodName>copy_vhd_from_second...) exitted with code 0
Oct 16 10:44:03 Xen-46-26-a fe: 19752 (/etc/xapi.d/plugins/vmops
<methodCall><methodName>kill_copy_process</methodNa...) exitted with code 0
Oct 16 10:44:04 Xen-46-26-a fe: 19759 (/opt/xensource/sm/LVMSR
<methodCall><methodName>vdi_detach</methodName><param...) exitted with code 0
Oct 16 10:44:04 Xen-46-26-a vhd-util: libvhd::vhd_validate_footer: invalid
footer cookie:
Oct 16 10:44:04 Xen-46-26-a vhd-util: libvhd::vhd_read_footer_at:
/dev/VG_XenStorage-d65e2216-05ad-de70-3941-07985aaaeba6/VHD-846a952c-0541-49cd-b8fb-10ad37a8a0fd:
reading footer at 0x007ffe00 failed: -22
Oct 16 10:44:04 Xen-46-26-a vhd-util: libvhd::vhd_read:
/dev/VG_XenStorage-d65e2216-05ad-de70-3941-07985aaaeba6/VHD-846a952c-0541-49cd-b8fb-10ad37a8a0fd:
read of 512 returned 0, errno: -22
Oct 16 10:44:04 Xen-46-26-a vhd-util: libvhd::vhd_validate_footer: invalid
footer cookie:
Oct 16 10:44:04 Xen-46-26-a vhd-util: libvhd::vhd_read_short_footer:
/dev/VG_XenStorage-d65e2216-05ad-de70-3941-07985aaaeba6/VHD-846a952c-0541-49cd-b8fb-10ad37a8a0fd:
failed reading short footer: -22
Oct 16 10:44:04 Xen-46-26-a vhd-util: libvhd::vhd_validate_footer: invalid
footer cookie:
Oct 16 10:44:04 Xen-46-26-a vhd-util: libvhd::vhd_read_footer_at:
/dev/VG_XenStorage-d65e2216-05ad-de70-3941-07985aaaeba6/VHD-846a952c-0541-49cd-b8fb-10ad37a8a0fd:
reading footer at 0x007ffe00 failed: -22
Oct 16 10:44:04 Xen-46-26-a vhd-util: libvhd::vhd_read:
/dev/VG_XenStorage-d65e2216-05ad-de70-3941-07985aaaeba6/VHD-846a952c-0541-49cd-b8fb-10ad37a8a0fd:
read of 512 returned 0, errno: -22
Oct 16 10:44:04 Xen-46-26-a vhd-util: libvhd::vhd_validate_footer: invalid
footer cookie:
Oct 16 10:44:04 Xen-46-26-a vhd-util: libvhd::vhd_read_short_footer:
/dev/VG_XenStorage-d65e2216-05ad-de70-3941-07985aaaeba6/VHD-846a952c-0541-49cd-b8fb-10ad37a8a0fd:
failed reading short footer: -22
----------------------------
If I change "system.vm.use.local.storage" to "false" and define NFS-based SR as
Primary Storage instead of local SR, the VMs are deployed without problems.
What can cause it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
