-----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-----
