You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Rafael Weingärtner <ra...@gmail.com> on 2018/01/03 17:16:28 UTC
Re: Upgrading to XenServer 7.x
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 <ti...@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" <pa...@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 <pd...@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
Re: Upgrading to XenServer 7.x
Posted by Khosrow Moossavi <km...@cloudops.com>.
Paul
I don't think that is relevant here (I'm not entirely sure though) but the
change was literal "xs-tools.iso" to "guest-tools.iso"
On Thu, Jan 4, 2018 at 5:11 AM, Rafael Weingärtner <
rafaelweingartner@gmail.com> wrote:
> But, this would not cause the exception. The exception that Pierre reported
> is only cause if we have SRs named "XenServer Tools" explicitly.
> Take a look at the piece of code:
>
> > Set<SR> srs = SR.getByNameLabel(conn, "XenServer Tools");
> > if (srs.size() != 1) {
> > throw new CloudRuntimeException("There are " + srs.size()
> > + " SRs with name XenServer Tools");
> > }
>
>
> If there was an SR called "XenServer Tools" and other called "Guest Tools",
> the exception would not be thrown.
>
> On Thu, Jan 4, 2018 at 5:50 AM, Paul Angus <pa...@shapeblue.com>
> wrote:
>
> > Hi Rafael,
> >
> > I believe that "XenServer Tools" has been renamed "Guest Tools" (or
> > something similar) in 7.1 and up.
> > Which may be causing the confusion. (https://issues.apache.org/
> > jira/browse/CLOUDSTACK-10197)
> >
> >
> >
> >
> > Kind regards,
> >
> > Paul Angus
> >
> > paul.angus@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
> > -----Original Message-----
> > From: Rafael Weingärtner [mailto:rafaelweingartner@gmail.com]
> > Sent: 03 January 2018 23:36
> > To: users@cloudstack.apache.org
> > Subject: Re: Upgrading to XenServer 7.x
> >
> > 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 <te...@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 <ti...@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" <pa...@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
> >
>
>
>
> --
> Rafael Weingärtner
>
Re: Upgrading to XenServer 7.x
Posted by Rafael Weingärtner <ra...@gmail.com>.
But, this would not cause the exception. The exception that Pierre reported
is only cause if we have SRs named "XenServer Tools" explicitly.
Take a look at the piece of code:
> Set<SR> srs = SR.getByNameLabel(conn, "XenServer Tools");
> if (srs.size() != 1) {
> throw new CloudRuntimeException("There are " + srs.size()
> + " SRs with name XenServer Tools");
> }
If there was an SR called "XenServer Tools" and other called "Guest Tools",
the exception would not be thrown.
On Thu, Jan 4, 2018 at 5:50 AM, Paul Angus <pa...@shapeblue.com> wrote:
> Hi Rafael,
>
> I believe that "XenServer Tools" has been renamed "Guest Tools" (or
> something similar) in 7.1 and up.
> Which may be causing the confusion. (https://issues.apache.org/
> jira/browse/CLOUDSTACK-10197)
>
>
>
>
> Kind regards,
>
> Paul Angus
>
> paul.angus@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
>
>
>
> -----Original Message-----
> From: Rafael Weingärtner [mailto:rafaelweingartner@gmail.com]
> Sent: 03 January 2018 23:36
> To: users@cloudstack.apache.org
> Subject: Re: Upgrading to XenServer 7.x
>
> 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 <te...@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 <ti...@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" <pa...@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
>
--
Rafael Weingärtner
RE: Upgrading to XenServer 7.x
Posted by Paul Angus <pa...@shapeblue.com>.
Hi Rafael,
I believe that "XenServer Tools" has been renamed "Guest Tools" (or something similar) in 7.1 and up.
Which may be causing the confusion. (https://issues.apache.org/jira/browse/CLOUDSTACK-10197)
Kind regards,
Paul Angus
paul.angus@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
-----Original Message-----
From: Rafael Weingärtner [mailto:rafaelweingartner@gmail.com]
Sent: 03 January 2018 23:36
To: users@cloudstack.apache.org
Subject: Re: Upgrading to XenServer 7.x
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 <te...@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 <ti...@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" <pa...@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
Re: Upgrading to XenServer 7.x
Posted by Rafael Weingärtner <ra...@gmail.com>.
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 <te...@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 <ti...@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" <pa...@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
Re: Upgrading to XenServer 7.x
Posted by Erik Weber <te...@gmail.com>.
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 <ti...@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" <pa...@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 <pd...@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
>