cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: RBD snapshot format
Date Thu, 29 Jan 2015 21:21:05 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 01/29/2015 10:05 PM, Logan Barfield wrote:
> 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.
> 

No, that won't work. Because the management server will then still
think it's in RAW format and store that in the database.

It has been a long time since I looked at this. I know I did some work
in this area and made some patches.

Wido

> 
> Thank You,
> 
> Logan Barfield Tranquil Hosting
> 
> 
> On Thu, Jan 29, 2015 at 3:52 PM, Wido den Hollander 
> <wido@widodh.nl> wrote:
> 
> 
> 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

iQIcBAEBAgAGBQJUyqRBAAoJEAGbWC3bPspCam8QALupIaRKc09pDT4Fk8bA0Bqs
TS97Mw+VIE8GMszLOt8sKadGerC/8/qLJ5j1xQkfPQWijim64JaebGmTEShQHNWu
SYvi/sHkqMLlgzrdsB7jW5rcFNCeQ6ZoncSLvZ9shepte5jaOJcjHQJs7cJmJa7F
6f2W4C9e7iBXLpddmM6A7jh1PCRo2sv+5hLR5Vxf/w93+3BZF9N8MTHyQfFIElpH
PP2hgnem7uOsV/4PzuvJ8Sy2U1/0SFLD9JOWop9aS7BcuqxmB2iB7YJlS/NGTG9V
pT+23edjDLAGAjUBdtol2VfqcXgdiXf3NTQuBS8XIaRDaTP5O1t96X24Ux7yo/1T
ptpcqmZCMIj4NTfv7SMln6nkCBZ4iX0kw36Sv3X1vKMAqyPnA57r6h65Y7h9IYK2
ihaDAjEByoLruvVMzr0wWR3kEmE5EWzkV5Za7Jy76QcQkJh6XDgXFkkc5RmO7/pE
ufyX7iQtukKbsRlYiFkOZzhVbTGTRzm8gNc1pge6cJmtGK0A6Jf4IZPHbAkE4Lyq
wcNR/OH2feYeqoKe9pFh06GC99kkl08uLRTuucnXia7Hb0GOX3u4uEvUEv77lPbh
xQiokSmxMtHqqBmMtSfcApfy4ZDz1ji+VAPixyvUI8bVpQBMieKEZRBgwXzaz+3P
8CoCyy5uX1HjwbRbMcMh
=2UKe
-----END PGP SIGNATURE-----

Mime
View raw message