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.createPatchVbd(Ci > > trixResourceBase.java:1435) > > > > > at > > > > > > > > > > > > > > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixRes > > ourceBase.java:1629) > > > > > at > > > > > > > > > > > > > > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(Ci > > trixResourceBase.java:553) > > > > > at > > > > > > > > > > > > > > > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest( > X > > enServer56Resource.java:73) > > > > > at > > > > > > > > > > > > > > > com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest > ( > > XenServer610Resource.java:104) > > > > > at > > > > > > > > > > > > > > > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache > > .java:186) > > > > > at > > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java > > > > :439) > > > > > at > > > > > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java: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$ScheduledFutureTask.r > > un(ScheduledThreadPoolExecutor.java:206) > > > > > at > > > > > > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecu > > 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)*
