You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by "Vladimir Ostrovsky (JIRA)" <ji...@apache.org> on 2012/10/16 14:53:03 UTC

[jira] [Created] (CLOUDSTACK-360) System VM template isn't copied from Secondary Storage to XenServer's local SR

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

[jira] [Commented] (CLOUDSTACK-360) System VM template isn't copied from Secondary Storage to XenServer's local SR

Posted by "Rohit Yadav (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CLOUDSTACK-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482139#comment-13482139 ] 

Rohit Yadav commented on CLOUDSTACK-360:
----------------------------------------

Are you using 2.2.14? If yes, pl. use asf master/4.0;
The environment field suggests:
CloudStack: 2.2.14
Hypervisor: XenServer 5.6 with SP2 and with CloudStack Support Pack 
                
> 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