Yes. There is a copy on the secondary storage if you're using vmware hypervisor but even that copy is deposited there by the management server.
--Alex > -----Original Message----- > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > Sent: Thursday, August 8, 2013 3:52 PM > To: dev@cloudstack.apache.org > Subject: Re: Quick Question about System VM problem > > I see. Thanks for that info, Alex. > > So, the systemvm.iso and patches reside with the CS MS? They are not > placed on secondary storage? > > > On Thu, Aug 8, 2013 at 4:44 PM, Alex Huang <alex.hu...@citrix.com> wrote: > > > CloudStack delivers all of the patches and systemvm.iso when it first > > connects to a xenserver. It then retrieves the version string and > > deposits that as a tag on the host. On all subsequent connects, > > cloudstack checks the tags and compares it with the version string. > > If they are different, it redeliver all of the files, overwriting the > > previous > files. > > > > So one thing you often have to be aware of during development is that > > if you are modifying scripts or the systemvm.iso during a build, it > > won't be delivered to the xenserver because the version string did not > > change and therefore still matches to the version tag on the host. > > This stems from a change in maven build because, cloudstack's version > > number used to have four parts. The last part was an incremental > > build number, so everytime you do a build, the build number changes > > and therefore script changes are delivered. Now, it only has three > > parts. It works fine for production upgrade but for developers, you > > have to remove the version tag on the xenserver host in order for any > script changes to be delivered. > > > > --Alex > > > > > -----Original Message----- > > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > > > Sent: Thursday, August 8, 2013 2:11 PM > > > To: dev@cloudstack.apache.org > > > Subject: Re: Quick Question about System VM problem > > > > > > Thanks, guys > > > > > > I ended up starting over from scratch (wiped out my CS environment, > > > restored my XenServer hosts from snapshots, etc.) and it appears to > > > work now. > > > > > > However, as a learning experience, Wei, can you tell me how > > > systemvm.iso gets to the XenServer host normally? Is it part of what > > > is seeded to secondary storage? When I look at my secondary storage > > > folders, I don't > > see > > > such a file (maybe it's under a different name or something?). > > > > > > Thanks! > > > > > > > > > On Thu, Aug 8, 2013 at 3:06 PM, Wei ZHOU <ustcweiz...@gmail.com> > wrote: > > > > > > > systemvm.iso is missing on your xenserver host. > > > > try again after copying ./console-proxy/dist/systemvm.iso to > > > > /usr/share/xcp/packages*/iso/ on host* > > > > > > > > > > > > 2013/8/8 Mike Tutkowski <mike.tutkow...@solidfire.com> > > > > > > > > > The CS MS is on Mac OS X. > > > > > > > > > > My secondary storage share is on Ubuntu 12.04. > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > On Thu, Aug 8, 2013 at 1:44 PM, Daan Hoogland > > > > > <daan.hoogl...@gmail.com > > > > > >wrote: > > > > > > > > > > > are you developing on windows, Mike? > > > > > > > > > > > > On Thu, Aug 8, 2013 at 9:22 PM, Mike Tutkowski > > > > > > <mike.tutkow...@solidfire.com> wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I must be missing something easy here. :) I've set up this > > > > > > > config > > > > many > > > > > > > times before and it's worked just fine (this is in 4.2): > > > > > > > > > > > > > > Two XenServer 6.1 hosts in a cluster. > > > > > > > Local storage is enabled in CS. > > > > > > > My secondary storage has the system template for XenServer. > > > > > > > Template routing-1 shows up under the local SR of one of my > > > > > > > hosts > > > > along > > > > > > > with ROOT-<some number>, but the system VM flickers on, then > > > > disappears > > > > > > and > > > > > > > I see this exception in the console: > > > > > > > > > > > > > > WARN [xen.resource.CitrixResourceBase] (DirectAgent-500:) > > > > > > > Catch > > > > > > Exception: > > > > > > > class com.cloud.utils.exception.CloudRuntimeException due to > > > > > > > com.cloud.utils.exception.CloudRuntimeException: can not > > > > > > > find > > > > > systemvmiso > > > > > > > com.cloud.utils.exception.CloudRuntimeException: can not > > > > > > > find > > > > > systemvmiso > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > com.cloud.hypervisor.xen.resource.CitrixResourceBase.createPatchVb > > > > d(Ci > > > > trixResourceBase.java:1435) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(Citri > > > > xRes > > > > ourceBase.java:1629) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeReques > > > > t(Ci > > > > trixResourceBase.java:553) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest > > > ( > > > X > > > > enServer56Resource.java:73) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > com.cloud.hypervisor.xen.resource.XenServer610Resource.executeReques > > > t > > > ( > > > > XenServer610Resource.java:104) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttac > > > he > > > > .java:186) > > > > > > > at > > > > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors. > > > > > > java > > > > > > :439) > > > > > > > at > > > > > > > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.jav > > > > > > > a:30 > > > > > > > 3) at > > > > > > > java.util.concurrent.FutureTask.run(FutureTask.java:138) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask > > > .a > > > > ccess$301(ScheduledThreadPoolExecutor.java:98) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTa > > > > sk.r > > > > un(ScheduledThreadPoolExecutor.java:206) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExe > > > cu > > > > tor.java:895) > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. > > > > java:918) > > > > > > > at java.lang.Thread.run(Thread.java:680) > > > > > > > > > > > > > > Thoughts on this? > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > -- > > > > > > > *Mike Tutkowski* > > > > > > > *Senior CloudStack Developer, SolidFire Inc.* > > > > > > > e: mike.tutkow...@solidfire.com > > > > > > > o: 303.746.7302 > > > > > > > Advancing the way the world uses the > > > > > > > cloud<http://solidfire.com/solution/overview/?video=play> > > > > > > > *(tm)* > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > *Mike Tutkowski* > > > > > *Senior CloudStack Developer, SolidFire Inc.* > > > > > e: mike.tutkow...@solidfire.com > > > > > o: 303.746.7302 > > > > > Advancing the way the world uses the > > > > > cloud<http://solidfire.com/solution/overview/?video=play> > > > > > *(tm)* > > > > > > > > > > > > > > > > > > > > > -- > > > *Mike Tutkowski* > > > *Senior CloudStack Developer, SolidFire Inc.* > > > e: mike.tutkow...@solidfire.com > > > o: 303.746.7302 > > > Advancing the way the world uses the > > > cloud<http://solidfire.com/solution/overview/?video=play> > > > *(tm)* > > > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *(tm)*
