cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Quick Question about System VM problem
Date Thu, 08 Aug 2013 22:51:56 GMT
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.Huang@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.tutkowski@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 <ustcweizhou@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.tutkowski@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.hoogland@gmail.com
> > > > >wrote:
> > > >
> > > > > are you developing on windows, Mike?
> > > > >
> > > > > On Thu, Aug 8, 2013 at 9:22 PM, Mike Tutkowski
> > > > > <mike.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message