cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Weingärtner <rafaelweingart...@gmail.com>
Subject Re: Upgrading to XenServer 7.x
Date Wed, 03 Jan 2018 23:35:37 GMT
Well, that seems to be the right thing. However, looking at the code:
com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.createPatchVbd(Connection,
String, VM), which is the one throwing the exception. It looks for an SR
that has the name "XenServer Tools". Then, in this SR, it will list all of
the VDIs, and look for a "systemvm.iso" to patch the system VM. Maybe, ACS
transfers the systemvm.iso to the SR named "XenServer Tools"?

The thing is that this method only wants a single SR named "XenServer
Tools". If we can confirm that after the upgrade, all of the SRs named
"XenServer Tools" have the same content, we can remove that logic
restriction.

On Wed, Jan 3, 2018 at 9:21 PM, Erik Weber <terbolous@gmail.com> wrote:

> Afaik the SR hosts the XS tools, not systemvm.iso.
>
> Those tools are provided by XenServer and usually differ between versions.
>
> Erik
>
> ons. 3. jan. 2018 kl. 18:16 skrev Rafael Weingärtner <
> rafaelweingartner@gmail.com>:
>
> > Thanks for the replies guys.
> > I have checked the code, and if there are more than one SR with the name
> > "XenServer Tools", it throws that exception.
> > These to SRs were created by XenServer during the upgrade process. Then,
> my
> > question is, are the content of these SRs the same? I mean, are the
> > "systemvm.iso" that they store the same? If so, we could remove this
> check
> > and use the first one we retrieve.
> >
> > Pierre, is it possible for you to check that?
> >
> > On Thu, Dec 28, 2017 at 6:21 PM, Sebastian Gomez <tiochan@gmail.com>
> > wrote:
> >
> > > Thank you for the explanation. Is good to know that there really were
> an
> > > incompatibility problem, and not a mistake during config.
> > >
> > > Thank you again for your work and time.
> > > Regards.
> > >
> > > El 28/12/2017 9:55, "Paul Angus" <paul.angus@shapeblue.com> escribió:
> > >
> > > > Sebastian,
> > > >
> > > > XenServer 7.1 and 7.2 aren't supported in 4.9.x  - the main fix is to
> > add
> > > > the guest OS mappings to the database. These have been added for
> 4.11,
> > > but
> > > > there seems to be a slight change in behaviour in XS7.1 when adding a
> > > host
> > > > to a cluster which is confusing CloudStack.
> > > >
> > > >
> > > >
> > > > Kind regards,
> > > >
> > > > Paul Angus
> > > >
> > > > paul.angus@shapeblue.com
> > > > www.shapeblue.com
> > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > > @shapeblue
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Sebastian Gomez [mailto:tiochan@gmail.com]
> > > > Sent: 28 December 2017 08:08
> > > > To: users@cloudstack.apache.org
> > > > Subject: Re: Upgrading to XenServer 7.x
> > > >
> > > > Hi all.
> > > >
> > > > I had a similar problem, but usign XenServer 7.2. It was a fresh
> > > > installation from scratch. The system vms where created, but them
> > > *could'nt
> > > > get the local link IP*, so the cloudstack agent never went up.
> > > >
> > > > After that, I found the compatibility matrix, where its specified
> that
> > > the
> > > > compatible versions of XenServer are up to 7.0...
> > > > http://docs.cloudstack.apache.org/projects/cloudstack-
> > > > release-notes/en/4.9.2.0/compat.html#supported-hypervisor-versions
> > > >
> > > > That's the point where I'm, trying to configure them with XS 7.0, but
> > > > unfortunately XS 7.0 does not provide drivers for our Broadcom
> > > > BCM57412 10Gb network eth adapters.
> > > > Here we are, working on how to add the drivers...
> > > >
> > > >
> > > > Good luck!
> > > >
> > > >
> > > >
> > > >
> > > > Atentamente,
> > > > Sebastián Gómez
> > > >
> > > > On Tue, Dec 26, 2017 at 5:12 PM, Pierre-Luc Dion <pdion@cloudops.com
> >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Just as FYI, we recently upgrade from 6.5 to xs 7.1, so far
> everthing
> > > > > is good. Then we add some hosts to Pool or reinstall some XenServer
> > to
> > > > > have proper new filesystem on dom0 which have more disk space for
> > > > /var/log!
> > > > >  then we ran into the situation where CloudStack fail to create
> > > > > Virtual Router in a XenServer cluster. Turns out that for some
> > unknown
> > > > > reason, adding a fresh installed xenserver to a cluster can create
> > new
> > > > > SR and VDI for xs-tools iso, this break cloudstack VR creation for
> > > > > some reason. So the easy fix is to forget non-shared SR containing
> > > > xs-tools VDI.
> > > > >
> > > > > Basically, if "xe vdi-list is-tools-iso=true" return more than one
> > > > > iso, CloudStack should fail to create Virtual-Router.
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>



-- 
Rafael Weingärtner

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