I ran that through my tester, it didn't like it. That actually kept
the system vms from starting. Since CopyCommand is used for both
template to template and template to primary, it seems that the
original template copy is fine but now this catches the case where the
source template is on primary and we are making a root disk.
copyTemplateToPrimaryStorage has:
if (!(imageStore instanceof NfsTO)) {
return new CopyCmdAnswer("unsupported protocol");
}
we should be calling 'cloneVolumeFromBaseTemplate', but the original
if statement is now too loose. I'll play with it a bit and see if I
can suggest a solution that works.
2013-09-17 17:58:07,178 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-2:null) Request:Seq 1-829816935: { Cmd ,
MgmtId: 52241639751, via: 1, Ver: v1, Flags: 100011,
[{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"bf53a7c6-1fed-11e3-a1ff-000c29d82947","origUrl":"http://download.cloud.com/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2","uuid":"bf53a7c6-1fed-11e3-a1ff-000c29d82947","id":3,"format":"QCOW2","accountId":1,"checksum":"6cea42b2633841648040becb588bd8f0","hvm":false,"displayText":"SystemVM
Template
(KVM)","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"8932daaf-272c-45c9-a078-d601dfc5ca56","id":1,"poolType":"Filesystem","host":"172.17.10.10","path":"/var/lib/libvirt/images","port":0}},"name":"routing-3","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"0c15b340-228b-48f1-88c4-b717ad08d4e3","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"8932daaf-272c-45c9-a078-d601dfc5ca56","id":1,"poolType":"Filesystem","host":"172.17.10.10","path":"/var/lib/libvirt/images","port":0}},"name":"ROOT-1","size":0,"volumeId":2,"vmName":"s-1-VM","accountId":1,"format":"QCOW2","id":2,"hypervisorType":"KVM"}},"executeInSequence":false,"wait":0}}]
}
2013-09-17 17:58:07,179 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-2:null) Processing command:
org.apache.cloudstack.storage.command.CopyCommand
2013-09-17 17:58:07,179 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-2:null) Seq 1-829816935: { Ans: , MgmtId:
52241639751, via: 1, Ver: v1, Flags: 10,
[{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"unsupported
protocol","wait":0}}] }
On Thu, Oct 17, 2013 at 1:45 PM, SuichII, Christopher
<chris.su...@netapp.com> wrote:
> 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
>
>
