[et-mgmt-tools] [patch] virt-convert add disk signature into virt-image format export

[Cole Robinson]

Joey Boggs wrote:
>>>
>>> It helps code readability if spacing is reasonably
>>> consistent throughout.
>>>
>>> Hmm, so I just tried the above. What that is essentially
>>> trying to do is read the entire disk into memory, then
>>> pass it off as a giant string to the sha function. Clearly
>>> this is not a workable solution. This also applies to
>>> the virt-image hash changes as well. Haven't looked into
>>> the correct way to do it though.
>>>
>>> This is also a rather large performance drain. So at the
>>> very least it should not be the default. That said, I
>>> don't know the optimal way to expose this option, or
>>> even if we should.
>> I think this will become important as we look to distribute the 
>> appliances either via RHN or on public sites. Also.. this makes us a 
>> bit more consistent with OVF.
>>
>> I am fine with making it off by default, and then causing the command 
>> line to turn it on.
>>
>> -- bk
> I'd rather it be right than kill performance and make it unusable at 
> best, should the imagefile be bigger than the machines memory.  If we 
> outsource it to run a system command is that feasible, since we're 
> dealing with big files? I know Cole was against that originally. I'll 
> keep looking for a better way and cleanup the variables as well. Making 
> it off by default is probably best too.
> 

When I was talking about performance, I was addressing the
'correct' way to do, when the 'read into memory' piece is
fixed. Even then, generating a checksum is a very slow
process if you are using a large disk (I used sha1sum on
a DVD iso and it took about 3-4 minutes).

So in this case, turning it off by default is the thing to
do, we can figure out a cli switch to enable it, but this
is all dependent on determining the correct way to use the
libraries. You'll just have to use a loop and read in blocks
of data at a time, and keep passing it to the library to 
update the hash.

- Cole