Actually, I don't think that will fix this (though it probably fixes something :-)
The issue I'm having is that we went from 'if source is a template on nfs and destination is primary storage' to 'if source is a template and destination is a template on primary storage'. We aren't copying 'template on secondary' -> 'template on primary', with CLVM we copy 'template on secondary' -> 'root disk on primary', since it's wasteful and slow to copy a thin template (say a 50G img of size 500MB) to a template on primary that's 50G, and then copy that 50G primary template to another 50G primary root disk, since the primary storage is neither thin nor clone-able. On Thu, Oct 17, 2013 at 1:16 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > Ok, let me test it. > > On Thu, Oct 17, 2013 at 12:56 PM, SuichII, Christopher > <chris.su...@netapp.com> wrote: >> Oh, I noticed this and created a fix, which I thought I already had >> submitted since it was a part of the storage refactoring a couple weeks >> back. I'll post the patch for review now. >> >> -- >> Chris Suich >> chris.su...@netapp.com >> NetApp Software Engineer >> Data Center Platforms – Cloud Solutions >> Citrix, Cisco & Red Hat >> >> On Oct 17, 2013, at 2:51 PM, Marcus Sorensen <shadow...@gmail.com> wrote: >> >>> Just posting this to dev for visibility. >>> >>> I think commit 180cfa19 broke CLVM primary storage for KVM. I'm >>> failing VM deploy from template. I've been building a 'sanity check' >>> test that focuses on the KVM specific suff (tests storage types and >>> supported host OS for now), and this bubbled up. >>> >>> Read more at: https://issues.apache.org/jira/browse/CLOUDSTACK-4887 >>
