Hi Wido, The relevant code for this is in:
I saw that the destination format is set to QCOW2 for "createTemplateFromVolume", but in "backupSnapshot" it's set to use the format of the source image "destFile.setFormat(snapshotDisk.getFormat());" I believe just changing the "backupSnapshot" code to the use QCOW2 "destFile.setFormat(PhysicalDiskFormat.QCOW2);" will work fine. I can submit a patch for that, but I wanted to make sure there wasn't some other reason for the RAW output first. Thank You, Logan Barfield Tranquil Hosting On Thu, Jan 29, 2015 at 3:52 PM, Wido den Hollander <w...@widodh.nl> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 01/29/2015 05:16 PM, Logan Barfield wrote: >> I was doing some testing earlier this week on a KVM cluster, and >> noticed that when using S3 for secondary storage snapshots on RBD >> primary storage take a lot longer than they do with NFS primary >> storage. >> >> I think this is due to the NFS snapshots being output/uploaded in >> QCOW2 format, while RBD snapshots are output in RAW format. It >> appears that even when using sparse RAW files they are uploaded to >> S3 with the 'allocated' size instead of the sparse size. >> > > The problem here lies in the code in CloudStack. Since the source > volume is in RAW format, the snapshot also becomes QCOW2. > > I remember that I wrote some patches for this, you might want to look > in the Git history. > >> My question is: Is there a good reason for RBD snapshots to be >> output as RAW instead of QCOW2? It appears that QCOW2 templates >> are automatically converted when deploying them as RBD, so that >> shouldn't be a problem. The only downside I can think of would be >> having to convert the RAW RBD data to QCOW2 as an extra step when >> creating snapshots, but even that seems like it would take less >> time than uploading the RAW images to S3. >> >> Thoughts? >> > > Like I said, I think I wrote patches for this. Qemu-img is used to > convert the RAW RBD into the snapshot, so QCOW2 should be no problem > as output format. But the code in CloudStack seems to assume that the > snapshot volume is always the same format as the source. > > Wido > > P.S.: I'm on vacation in Norway at the moment, so I'm pretty laggy > with replying. > >> >> Thank You, >> >> Logan Barfield Tranquil Hosting >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJUyp2CAAoJEAGbWC3bPspCav8P/RyDGic4E+ngxaZ118a0N8H3 > VpIQG/oZR//Lw/iU8FNGbKLcR3W3S4LRtNj/tqaDChaDIeOUEAsyF44/lRcZXayM > plXAPRRiUhJ5UL3Fz7+fh2eCfDu269Pwgq2J6ATDi1p39bi0jcJdRYBe0FyrVbP2 > +ahA//zoppN3vLJKVew6h/h5k4XVhSpKJ9mMZAE0uTi5ontyG7UJMHt3pKGS/ssI > 0nEgCCYYGrzicKFkhW2ZQdWvEtyrfNX/Okiq4/msJ7LJ+9ivUp24hO4ePFRrifWp > mmERnBtp4sUNP19zId0emCO5E/pkM8Inbkwzlv21x6TfDQ62OHs1dK4i4ZIQXT0T > F4O/PXUCJ45xmkcaP8su5TrnupD5Y5CxjInfMDrfDwHZwSEbHPvANCZTh82D7C1l > TOmDqWwWcShOYXQfJANqYPn6a2wMeqjFQtiiG9CRC6Wf6FomFh37VKUSQuUBVf7X > IP/Q9k5qTQ0FXXf7PseSIgLyOBMC8cRDvVU3QpcJ61Zjot2WETrYtujL9PjiSU1G > KpCXHWAXrZmXFHhC/mXuiHHKjbn61BpJGqAdn2oyeO0ma6oLTdNLMw0wMjAApDee > IT/UFhidnUEbhbN4mV1Kcehng+uX6yXcun0n4JvDeu+b0Aqmtc7PpomNSPd4dlnp > KF3OeZOQPrR1FcMwA+Tq > =9yJy > -----END PGP SIGNATURE-----
