cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From AWeber - Benjamin Krein <b...@aweber.com>
Subject Re: Copying templates between availability zones
Date Thu, 02 Aug 2012 17:55:37 GMT

On Aug 2, 2012, at 1:50 PM, AWeber - Benjamin Krein wrote:

> When I try to copy a template from one availability zone to another the webui says it
succeeds, but the copy never shows up & I see this in the management log:
> 
> 2012-08-02 17:44:00,935 DEBUG [agent.transport.Request] (Timer-6:null) Seq 12-1476463345:
Sending  { Cmd , MgmtId: 161334717904, via: 12, Ver: v1, Flags: 100011, [{"storage.DownloadProgressCommand":{"jobId":"7b468191-a7dc-41bf-8453-9e39b01b5fba","request":"GET_STATUS","hvm":true,"description":"Ubuntu10.04.4
64-bit (5GB)","checksum":"393d4aebf205603314affb8cd4d58d64","auth":{"userName":"cloud","password":"XXXXXXXXXXXXX"},"maxDownloadSizeInBytes":53687091200,"id":205,"url":"https://10-1-6-126.realhostip.com/copy/SecStorage/52659020-ee26-38cc-bca1-d037e65522a5/template/tmpl/2/205//50cfbdf4-1ae5-43ee-af9d-df9e73f56593.qcow2","format":"QCOW2","accountId":2,"name":"50cfbdf4-1ae5-43ee-af9d-df9e73f56593","secUrl":"nfs://myhost.internal.net/storage/cloud-sec2","wait":0}}]
}
> 
> 2012-08-02 17:44:00,977 DEBUG [agent.transport.Request] (AgentManager-Handler-1:null)
Seq 12-1476463345: Processing:  { Ans: , MgmtId: 161334717904, via: 12, Ver: v1, Flags: 10,
[{"storage.DownloadAnswer":{"jobId":"7b468191-a7dc-41bf-8453-9e39b01b5fba","downloadPct":0,"errorString":"
HTTP Server returned 403 (expected 200 OK) ","downloadStatus":"NOT_DOWNLOADED","downloadPath":"/mnt/SecStorage/16d441cf-f675-343b-884e-2ea5677773e8/template/tmpl/2/205/dnld4460230303792654544tmp_","templateSize":0,"templatePhySicalSize":0,"result":false,"wait":0}}]
}
> 
> I do not see the 403 in the Apache logs of the storage VMs.  I can select "Download Template"
from the actions & successfully download the qcow through the webui.


I should also note that I see the above log lines over and over again even after making the
initial request.  It's almost like the initial request is stuck & no other requests are
actually doing anything.  I've tried destroying/rebuilding the storage VMs & restarting
the cloud-management service followed by re-running cloud-setup-management several times to
no avail.  

I've also set the global 'secstorage.allowed.internal.sites' to match our internal subnet
(10.1.0.0/16) which you can see that the storage VM request is in along with the secondary
storage, agents, etc.


--
Benjamin Krein

Mime
View raw message