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 < [email protected]> 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 <[email protected]> > 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 > > > > [email protected] > > www.shapeblue.com > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > @shapeblue > > > > > > > > > > -----Original Message----- > > From: Rafael Weingärtner [mailto:[email protected]] > > Sent: 03 January 2018 23:36 > > To: [email protected] > > 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 <[email protected]> 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 < > > > [email protected]>: > > > > > > > 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 <[email protected]> > > > > 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" <[email protected]> > > 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 > > > > > > > > > > > > [email protected] > > > > > > www.shapeblue.com > > > > > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Sebastian Gomez [mailto:[email protected]] > > > > > > Sent: 28 December 2017 08:08 > > > > > > To: [email protected] > > > > > > 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 < > > [email protected] > > > > > > > > > > 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 >
