Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of Edison.su@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Edison Su <Edison.su@citrix.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Subject: RE: Master broken on systemVM start
Thread-Topic: Master broken on systemVM start
Thread-Index: 
 AQHOb2zFQ37YZziYN0KNSqcCYhb/K5lGchmAgAADp4CAAAFXgIAAAPOAgAABWwCAAAFNgIAAl+IAgAQawYCAAARGgIAAn+SAgAAM3ID//414EA==
Date: Fri, 28 Jun 2013 17:38:19 +0000
Message-ID: <77B337AF224FD84CBF8401947098DD87056EA3@SJCPEX01CL01.citrite.net>
References: <20130628070313.GA8724@cloud-2.local>
 <CDF306BA.40772%min.chen@citrix.com> <20130628172131.GB3249@cloud-2.local>
In-Reply-To: <20130628172131.GB3249@cloud-2.local>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Devcloud has a trick to clean up systemvm.iso:
There is a bug in xapi on Ubuntu/debian(not sure the bug still there in the=
 latest debian or not), which can't attach an ISO to a VM. I worked around =
the bug by creating a VDI on primary storage, copy systemvm iso into that V=
DI, then attach the vdi into system vm. The downside of this workaround is =
that, the VDI is not synced with systemvm iso.
In order to clean up devcloud, need to either clean up primary storage, or =
restore devcloud from snapshot for each run in your test infra.

> -----Original Message-----
> From: Prasanna Santhanam [mailto:tsp@apache.org]
> Sent: Friday, June 28, 2013 10:22 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Master broken on systemVM start
>=20
> I deleted all traces of systemvm.iso from my codebase $ find . -name
> systemvm.iso | xargs -n1 rm -f
>=20
> Then reverted my devcloud snapshot to old state and don't see this error
> again.
>=20
> I wonder by mvn doesn't do a good job of cleaning though :/
>=20
> Thanks for the fixes to the bugs and the upcoming fixes for the new ones.=
 I'll
> be switching over the test infra to run object store backed secondary onl=
y
> from next week so we should have more results.
>=20
> --
> Prasanna.,
>=20
> On Fri, Jun 28, 2013 at 04:35:29PM +0000, Min Chen wrote:
> > Prasanna, glad to know that CLOUDSTACK-3137 is resolved. I fixed
> > CLOUDSTACK-3249 yesterday for a corner case reported by Alena, but I
> > could not reproduce CLOUDSTACK-3137 on my environment at all. For the
> > JSON issue, I can only tell that it is inconsistent systemvm issue
> > between management server and system vm. In 4.2, we changed
> > ArrayTypeAdaptor to return full qualified command class name, so I
> > don't quite get why you are still seeing the abbreviated command name
> > in your log. Yes, StartupSecondaryStorageCommand is still there. From
> > your log, it seems that your ssvm has the old code.
> >
> > Thanks
> > -min
> >
> > On 6/28/13 12:03 AM, "Prasanna Santhanam" <tsp@apache.org> wrote:
> >
> > >On Fri, Jun 28, 2013 at 12:17:55PM +0530, Prasanna Santhanam wrote:
> > >> On Tue, Jun 25, 2013 at 04:07:08PM +0000, Min Chen wrote:
> > >> > Json deserialization issue is caused by out-of-dated systemvm.iso
> > >> > on
> > >>your
> > >> > hypervisor host. You need rebuilding systemvm.iso and deployed to
> > >> > your hypervisor host.
> > >> >
> > >>
> > >> CLOUDSTACK-3137 exists and seems to be a problem with HA and
> > >> systemVMs. The JSON serialization also exists for me despite
> > >> rebuidling the systemvm with -Dsystemvm.
> > >
> > >Ok - CLOUDSTACK-3137 _may_ have been fixed. the last few test-matrix
> > >jobs have succeeded. Perhaps related to fix for CLOUDSTACK-3249.
> > >
> > >>
> > >> I see the deserialization error when the ssvm agent sends this to
> > >> management server:
> > >>
> > >> 2013-06-28 06:42:50,609 DEBUG [cloud.agent.Agent]
> > >>(Agent-Handler-1:) Sending Startup: Seq -1-2:  { Cmd , MgmtId: -1, vi=
a: -1,
> Ver: v1, Flags:
> > >>101,
> > >>[{"StartupSecondaryStorageCommand":{"type":"SecondaryStorage","da
> taC
> > >>enter
> > >>":"1","pod":"1","guid":"s-1-VM-
> NfsSecondaryStorageResource","name":"
> > >>s-1-V
> > >>M","version":"4.2.0-SNAPSHOT","iqn":"NoIqn","publicIpAddress":"192.1
> > >>68.56
> > >>.144","publicNetmask":"255.255.255.0","publicMacAddress":"06:5c:ac:00
> :00:
> > >>42","privateIpAddress":"192.168.56.217","privateMacAddress":"06:aa:84
> :00:
> > >>00:12","privateNetmask":"255.255.255.0","storageIpAddress":"192.168.
> > >>56.21
> > >>7","storageNetmask":"255.255.255.0","storageMacAddress":"06:aa:84:0
> 0
> > >>:00:1 2","resourceName":"NfsSecondaryStorageResource","wait":0}}] }
> > >>
> > >> This happens both when I have a s3 store added and a regular nfs
> > >>storage added.
> > >> Is the startupcommand still reqd?
> > >>
> > >> --
> > >> Prasanna.,
> > >>
> > >> ------------------------
> > >> Powered by BigRock.com
> > >
> > >--
> > >Prasanna.,
> > >
> > >------------------------
> > >Powered by BigRock.com
> > >
>=20
>=20
> ------------------------
> Powered by BigRock.com