Hm, interesting.
Since nothing else in the if/else if series there depends on the src being a
template, I'd imagine it would be safe to just have the check be:
} else if (srcData.getObjectType() == DataObjectType.TEMPLATE &&
destDataStore.getRole() == DataStoreRole.Primary) {
In hindsight, adding the check for the destination being a template was just
overkill and shouldn't have been added. So, if that fixes your problem, I
believe it is in line with that Edison and I were doing with the storage
subsystem, however, we should check with him as well.
--
Chris Suich
chris.su...@netapp.com<mailto:chris.su...@netapp.com>
NetApp Software Engineer
Data Center Platforms – Cloud Solutions
Citrix, Cisco & Red Hat
On Oct 17, 2013, at 3:29 PM, Marcus Sorensen
<shadow...@gmail.com<mailto:shadow...@gmail.com>> wrote:
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<mailto:shadow...@gmail.com>> wrote:
Ok, let me test it.
On Thu, Oct 17, 2013 at 12:56 PM, SuichII, Christopher
<chris.su...@netapp.com<mailto: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<mailto: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
