You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Pierre-Luc Dion <pd...@cloudops.com> on 2017/12/26 16:12:42 UTC
Upgrading to XenServer 7.x
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.
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
>
Re: Upgrading to XenServer 7.x
Posted by Rafael Weingärtner <ra...@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
RE: Upgrading to XenServer 7.x
Posted by Sebastian Gomez <ti...@gmail.com>.
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.
> >
>
RE: Upgrading to XenServer 7.x
Posted by Paul Angus <pa...@shapeblue.com>.
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.
>
Re: Upgrading to XenServer 7.x
Posted by Sebastian Gomez <ti...@gmail.com>.
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.
>
Re: Upgrading to XenServer 7.x
Posted by Pierre-Luc Dion <pd...@cloudops.com>.
Hi Rafael,
you would see something like this in management-server.log:
Catch Exception: class com.cloud.utils.exception.CloudRuntimeException due
to com.cloud.utils.exception.CloudRuntimeException: There are 2 SRs with
name XenServer Tools
com.cloud.utils.exception.CloudRuntimeException: There are 2 SRs with name
XenServer Tools
at
com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.createPatchVbd(CitrixResourceBase.java:1065)
at
com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:98)
at
com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:53)
at
com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
It does not prevent to create VMs but fail to create new VR.
On Tue, Dec 26, 2017 at 2:24 PM, Rafael Weingärtner <
rafaelweingartner@gmail.com> wrote:
> yes, those are the log entries I was talking about.
>
> On Tue, Dec 26, 2017 at 5:18 PM, Pierre-Luc Dion <pd...@cloudops.com>
> wrote:
>
> > VR creation was failing with error logs in cloudstack-management.log. I
> > don't have logs details in hand, is this what you are looking for ?
> >
> > I have not created a bug in Jira because it seams to be a post upgrade
> > XenServer issue more than CloudStack at the moment, and is easy to
> resolve.
> >
> >
> > *Pierre-Luc DION*
> > Architecte de Solution Cloud | Cloud Solutions Architect
> > t 855.652.5683
> >
> > *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Tue, Dec 26, 2017 at 11:48 AM, Rafael Weingärtner <
> > rafaelweingartner@gmail.com> wrote:
> >
> > > Did you see any exception regarding this issue to share with us?
> > >
> > > On Tue, Dec 26, 2017 at 2: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
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>
Re: Upgrading to XenServer 7.x
Posted by Rafael Weingärtner <ra...@gmail.com>.
yes, those are the log entries I was talking about.
On Tue, Dec 26, 2017 at 5:18 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
> VR creation was failing with error logs in cloudstack-management.log. I
> don't have logs details in hand, is this what you are looking for ?
>
> I have not created a bug in Jira because it seams to be a post upgrade
> XenServer issue more than CloudStack at the moment, and is easy to resolve.
>
>
> *Pierre-Luc DION*
> Architecte de Solution Cloud | Cloud Solutions Architect
> t 855.652.5683
>
> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Tue, Dec 26, 2017 at 11:48 AM, Rafael Weingärtner <
> rafaelweingartner@gmail.com> wrote:
>
> > Did you see any exception regarding this issue to share with us?
> >
> > On Tue, Dec 26, 2017 at 2: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
> >
>
--
Rafael Weingärtner
Re: Upgrading to XenServer 7.x
Posted by Pierre-Luc Dion <pd...@cloudops.com>.
VR creation was failing with error logs in cloudstack-management.log. I
don't have logs details in hand, is this what you are looking for ?
I have not created a bug in Jira because it seams to be a post upgrade
XenServer issue more than CloudStack at the moment, and is easy to resolve.
*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683
*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_
On Tue, Dec 26, 2017 at 11:48 AM, Rafael Weingärtner <
rafaelweingartner@gmail.com> wrote:
> Did you see any exception regarding this issue to share with us?
>
> On Tue, Dec 26, 2017 at 2: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 Rafael Weingärtner <ra...@gmail.com>.
Did you see any exception regarding this issue to share with us?
On Tue, Dec 26, 2017 at 2: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