"qemu-img info <filename>" will also give you the information what type the file is.
-----Ursprüngliche Nachricht----- Von: Marcus [mailto:shadow...@gmail.com] Gesendet: Mittwoch, 10. Juni 2015 01:54 An: d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Betreff: Re: Problem Upload Windows volume to ACS 4.5.1 Looks like it is seeing a raw disk, when you specified it was QCOW2. That's what the 'file' command is doing. We used to just trust the name of the file, but this was enhanced to inspect the first 1MB of the download and validate that you are supplying the image format that CS expects. Because the first 1MB shows that this image has a boot sector, I'm assuming it is a raw disk image, instead of a qcow2. Note that CloudStack 4.5 should support raw format for KVM images, but you have to specify it on the API. [root@devcloud-kvm7 tmp]# qemu-img create -f qcow2 img.qcow2 1G Formatting 'img.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 lazy_refcounts=off [root@devcloud-kvm7 tmp]# qemu-img create -f raw img.raw 1G Formatting 'img.raw', fmt=raw size=1073741824 [root@devcloud-kvm7 tmp]# file img.qcow2 img.qcow2: QEMU QCOW Image (v3), 1073741824 bytes [root@devcloud-kvm7 tmp]# parted img.raw mklabel New disk label type? msdos [root@devcloud-kvm7 tmp]# file img.raw img.raw: x86 boot sector, code offset 0xb8 On Tue, Jun 9, 2015 at 3:01 AM, Jochim, Ingo <ingo.joc...@bautzen-it.de> wrote: > Hi Andrija, > > have you tried to convert (qemu-img convert) it to RAW and upload then? > Ceph is using RAW devices. The conversion takes place on storage > migration but on upload? > > Regards, > Ingo > > -----Ursprüngliche Nachricht----- > Von: Andrija Panic [mailto:andrija.pa...@gmail.com] > Gesendet: Dienstag, 9. Juni 2015 10:24 > An: d...@cloudstack.apache.org; users@cloudstack.apache.org > Betreff: Problem Upload Windows volume to ACS 4.5.1 > > HI guys, > > we try to move some volumes from one ACS installation to another (from > 4.3.2 to 4.5.1). > > Since we are using CEPH, and volume extract/download doesn't work at > the moment, we do workarround, we snapshots Windows DATA volume, > convert to template, and then we extract URL / download. > > Then we use this URL to "Upload Volume" to ACS 4.5.1 - but it fails > almoust imiddiately with error inside SSVM (nothing usefull in > management > log) - and the volume is deleted from ACS: > > I see there is inspecting disk with "file" commands...any thought why > is this failing ? > > These are source Windows DATA disk btw: > > 2015-06-09 07:58:47,811 DEBUG [cloud.agent.Agent] > (agentRequest-Handler-10:null) Request:Seq 81-4133460032995983410: { > Cmd , > MgmtId: 90520741174948, via: 81, Ver: v1, Flags: 100011, > [{"org.apache.cloudstack.storage.command.DownloadCommand":{"hvm":false > ,"maxDownloadSizeInBytes":5497558138880,"id":468,"resourceType":"VOLUM > E","installPath":"volumes/2/468","_store":{"com.cloud.agent.api.to.Nfs > TO":{"_url":"nfs:// > 10.13.2.1/data/tank/secondary","_role":"Image"}},"url":" > http://46.232.180.244/userdata/6f2280e7-86d6-4fc7-abe8-e2bbfdeed442.qc > ow2 ","format":"QCOW2","accountId":2,"name":"andrija2","wait":0}}] > } > 2015-06-09 07:58:47,814 DEBUG [cloud.agent.Agent] > (agentRequest-Handler-10:null) Processing command: > org.apache.cloudstack.storage.command.DownloadCommand > 2015-06-09 07:58:47,815 INFO > [storage.resource.NfsSecondaryStorageResource] > (agentRequest-Handler-10:null) Determined host 10.13.2.1 corresponds > to IP > 10.13.2.1 > 2015-06-09 07:58:47,873 INFO > [storage.template.HttpTemplateDownloader] > (agentRequest-Handler-10:null) No credentials configured for host= > 46.232.180.244:80 > 2015-06-09 07:58:47,895 INFO > [storage.template.HttpTemplateDownloader] > (pool-1-thread-3:null) Starting download from > http://46.232.180.244/userdata/6f2280e7-86d6-4fc7-abe8-e2bbfdeed442.qc > ow2 > to > > /mnt/SecStorage/dd40674b-575d-3bd2-87b3-7f1e1db4c02e/volumes/2/468/dnl > d8533335093017660470tmp_ remoteSize=21474836480 , max > size=5497558138880 > 2015-06-09 07:58:47,909 DEBUG [utils.script.Script] > (pool-1-thread-3:null) > Executing: /bin/bash -c file > > /mnt/SecStorage/dd40674b-575d-3bd2-87b3-7f1e1db4c02e/volumes/2/468/dnl > d8533335093017660470tmp_ > | cut -d: -f2 > 2015-06-09 07:58:47,936 DEBUG [utils.script.Script] > (pool-1-thread-3:null) Execution is successful. > 2015-06-09 07:58:47,941 INFO [storage.template.DownloadManagerImpl] > (pool-1-thread-3:null) Download Completion for jobId: > c95b3d60-f904-4ecc-ab9f-7ed1c36eba20, status=UNRECOVERABLE_ERROR > 2015-06-09 07:58:47,942 INFO [storage.template.DownloadManagerImpl] > (pool-1-thread-3:null) local: > > /mnt/SecStorage/dd40674b-575d-3bd2-87b3-7f1e1db4c02e/volumes/2/468/dnl > d8533335093017660470tmp_, bytes=1053854, error=Template content is > unsupported, or mismatch between selected format and template content. > Found : x86 boot sector; partition 1, pct=0 > 2015-06-09 07:58:50,876 DEBUG [cloud.agent.Agent] > (agentRequest-Handler-10:null) Seq 81-4133460032995983410: { Ans: , > MgmtId: 90520741174948, via: 81, Ver: v1, Flags: 10, > [{"com.cloud.agent.api.storage.DownloadAnswer":{"jobId":"c95b3d60-f904 > -4ecc-ab9f-7ed1c36eba20","downloadPct":0,"errorString":"Template > content is unsupported, or mismatch between selected format and > template content. Found : x86 boot sector; partition > 1","downloadStatus":"DOWNLOAD_ERROR","downloadPath":"/mnt/SecStorage/d > d40674b-575d-3bd2-87b3-7f1e1db4c02e/volumes/2/468/dnld8533335093017660 > 470tmp_","installPath":"volumes/2/468","templateSize":0,"templatePhySi > calSize":0,"result":true,"details":"Template > content is unsupported, or mismatch between selected format and > template content. Found : x86 boot sector; partition 1","wait":0}}] } > > -- > > Andrija Panić > > -- > This email was Virus checked by UTM 9. http://www.sophos.com > > -- > This email was Virus checked by UTM 9. http://www.sophos.com > -- This email was Virus checked by UTM 9. http://www.sophos.com
