RE: incluide host to Cloudsctack

[Anggy Lorena Coronado Salamanca]

Hi,

Is it possible that I can get the host to the pool with different amount of CPU?
*This is a Xen

Regards,
[firmalore]

De: Sanjeev Neelarapu [mailto:sanjeev.neelar...@accelerite.com]
Enviado el: Monday, June 13, 2016 11:47 PM
Para: users@cloudstack.apache.org
Asunto: RE: incluide host to Cloudsctack

Hi,

If it is a xen/vmware host, first we need to add it in pool either in xencenter 
or vcenter , then we have to add it in CS.

Best Regards,
Sanjeev N
Chief Product Engineer, Accelerite
Off: +91 40 6722 9368 | EMail: 
sanjeev.neelar...@accelerite.com
[cid:image001.png@01D18361.DE542D60]

From: Anggy Lorena Coronado Salamanca [mailto:anggy.coron...@compufacil.com.co]
Sent: Tuesday, June 14, 2016 3:03 AM
To: users@cloudstack.apache.org
Subject: incluide host to Cloudsctack

Hi guys,

Is possible to include a host to an existing pool in CloudStack? What is the 
right way to do it?

Regards,

[firma]

AVISO LEGAL: Este correo electrónico incluyendo sus anexos, contiene 
información confidencial, si usted no es el destinatario intencional, se le 
informa que cualquier uso, difusión, distribución o copiado de esta 
comunicación está terminantemente prohibido, hacerlo podría tener consecuencias 
legales como las contenidas en la Ley 1273 de 2009, Ley 1581 de 2012 y todas 
las que le apliquen. Si ha recibido este correo por error, por favor bórrelo. 
Si usted es el destinatario, le solicitamos mantener reserva sobre el 
contenido, los datos o información de contacto del remitente y en general sobre 
la información de este documento y/o archivos adjuntos, a no ser que exista una 
autorización explícita. Este mensaje y sus anexos han sido revisados con 
software antivirus, para evitar que contenga código malicioso que pueda afectar 
sistemas de cómputo, sin embargo es responsabilidad del destinatario confirmar 
este hecho en el momento de su recepción. LEGAL NOTICE: This email, including 
its attachments, contains confidential information, if you are not the intended 
recipient, be advised that any use, dissemination, distribution or copying of 
this communication is strictly prohibited, so could have legal consequences as 
those contained in the Act 1273 of 2009, Act 1581 of 2012 and all that apply. 
If you have received this email in error, please delete it. If you are the 
recipient, we request you maintain secrecy about the content, data or 
information contact the sender and in general on the information in this 
document and / or attachments, unless there is an explicit authorization. This 
message and its attachments have been checked with antivirus software to avoid 
containing malicious code that may affect computer systems, however it is the 
responsibility of the recipient to confirm this fact at the time of receipt.

DISCLAIMER == This e-mail may contain privileged and confidential 
information which is the property of Accelerite, a Persistent Systems business. 
It is intended only for the use of the individual or entity to which it is 
addressed. If you are not the intended recipient, you are not authorized to 
read, retain, copy, print, distribute or use this message. If you have received 
this communication in error, please notify the sender and delete all copies of 
this message. Accelerite, a Persistent Systems business does not accept any 
liability for virus infected mails.

AVISO LEGAL: Este correo electrónico incluyendo sus anexos, contiene 
información confidencial, si usted no es el destinatario intencional, se le 
informa que cualquier uso, difusión, distribución o copiado de esta 
comunicación está terminantemente prohibido, hacerlo podría tener consecuencias 
legales como las contenidas en la Ley 1273 de 2009, Ley 1581 de 2012 y todas 
las que le apliquen. Si ha recibido este correo por error, por favor bórrelo. 
Si usted es el destinatario, le solicitamos mantener reserva sobre el 
contenido, los datos o información de contacto del remitente y en general sobre 
la información de este documento y/o archivos adjuntos, a no ser que exista una 
autorización explícita. Este mensaje y sus anexos han sido revisados con 
software antivirus, para evitar que contenga código malicioso que pueda afectar 
sistemas de cómputo, sin embargo es responsabilidad del destinatario confirmar 
este hecho en el momento de su recepción. LEGAL NOTICE: This email, including 
its attachments, contains confidential information, if you are not the intended 
recipient, be advised that any use, dissemination, distribution or copying of 
this communication is strictly prohibited, so could have legal consequences as 
those contained in the Act 1273 of 2009, Act 1581 of 2012 and all that apply. 
If you have received this email in error, please delete it. If you are the 
recipient, we request you maintain secrecy about the content, data or 
information contact the sender and in general on the information in this 
document and / or 

RE: ACS 4.3 & VMware CPU Allocation

[Timothy Lothering]

Thanks Kirk, will give it a try

Regards,

Timothy Lothering
On 14 Jun 2016 20:56, "Kirk Kosinski"  wrote:

> Hi, you can configure the cores per socket on the template.  I'm not sure
> if this works in CloudStack 4.3 but it should in 4.4 and newer. [1]  It is
> configured by adding a detail with cpu.corespersocket=# to the template.
> I'm not sure if this is possible in the UI, so if not, try the
> updateTemplate API. [2]
>
> Best regards,
> Kirk
>
> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-5891
> [2]
> http://cloudstack.apache.org/api/apidocs-4.8/root_admin/updateTemplate.html
>
> kirk.kosin...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HS
> @shapeblue
>
>
>
> -Original Message-
> From: Timothy Lothering [mailto:tlother...@gmail.com]
> Sent: Tuesday, June 14, 2016 2:49 AM
> To: users@cloudstack.apache.org
> Subject: Re: ACS 4.3 & VMware CPU Allocation
>
> Hello Community,
>
>
>
> We have found a very interesting issue with CPU allocation in ACS 4.3 and
> VMware. When a Service Offering is configured, you can choose the number of
> Cores and clock speed, which is simple enough. The problem comes in on HOW
> the cores are assigned.
>
>
>
> In VMware at least, each core is assigned as a vSocket, with 1 vCore. As an
> example:
>
>
>
> 1. Service Offering defined is 8 Cores @ 2.5GHz,
>
> 2. Instance is provisioned as 8 vSockets with 1vCore per Socket
>
> 3. OS displays all 8 "CPUs"
>
> 4. Happiness!
>
>
>
> But, when you are using Core based licensing with products such as
> Microsoft SQL 2014 Standard, there is a limit on the number of supported
> "physical"
> sockets, in this case, 4.
>
>
>
> So when you run a SQL query/command, only 4 of the 8 cores are used, the
> only way around this is to change the VMware settings to 4x vSockets with
> 2x vCores per socket. There is a performance hit as described here:
>
> http://blogs.vmware.com/vsphere/2013/10/does-corespersocket-affect-performan
> ce.html, but the main issue is that Customers are trying to use all
> available resources.
>
>
>
> My questions from the info above:
>
>
>
> 1. Will there be future support to define vSockets and vCores per
> vSocket in a future release of ACS?
>
> 2. What is the impact on ACS Usage and Management reporting if we
> change
> the vSockets manually? (on VMware itself)
>
>
>
> Your insights would be appreciated.
>
>
>
> Regards
>
>
>
> Tim
>
>
>
>

RE: ACS 4.3 & VMware CPU Allocation

[Kirk Kosinski]

Hi, you can configure the cores per socket on the template.  I'm not sure if 
this works in CloudStack 4.3 but it should in 4.4 and newer. [1]  It is 
configured by adding a detail with cpu.corespersocket=# to the template.  I'm 
not sure if this is possible in the UI, so if not, try the updateTemplate API. 
[2]

Best regards,
Kirk

[1] https://issues.apache.org/jira/browse/CLOUDSTACK-5891
[2] http://cloudstack.apache.org/api/apidocs-4.8/root_admin/updateTemplate.html

kirk.kosin...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HS
@shapeblue



-Original Message-
From: Timothy Lothering [mailto:tlother...@gmail.com] 
Sent: Tuesday, June 14, 2016 2:49 AM
To: users@cloudstack.apache.org
Subject: Re: ACS 4.3 & VMware CPU Allocation

Hello Community,

 

We have found a very interesting issue with CPU allocation in ACS 4.3 and 
VMware. When a Service Offering is configured, you can choose the number of 
Cores and clock speed, which is simple enough. The problem comes in on HOW the 
cores are assigned.

 

In VMware at least, each core is assigned as a vSocket, with 1 vCore. As an
example:

 

1. Service Offering defined is 8 Cores @ 2.5GHz,

2. Instance is provisioned as 8 vSockets with 1vCore per Socket

3. OS displays all 8 "CPUs"

4. Happiness!

 

But, when you are using Core based licensing with products such as Microsoft 
SQL 2014 Standard, there is a limit on the number of supported "physical"
sockets, in this case, 4.

 

So when you run a SQL query/command, only 4 of the 8 cores are used, the only 
way around this is to change the VMware settings to 4x vSockets with 2x vCores 
per socket. There is a performance hit as described here:
http://blogs.vmware.com/vsphere/2013/10/does-corespersocket-affect-performan
ce.html, but the main issue is that Customers are trying to use all available 
resources.

 

My questions from the info above:

 

1. Will there be future support to define vSockets and vCores per
vSocket in a future release of ACS?

2. What is the impact on ACS Usage and Management reporting if we change
the vSockets manually? (on VMware itself)

 

Your insights would be appreciated.

 

Regards

 

Tim

 

RE: PERSISTANT VLANID FOR VIRTUAL MACHINE

[Kirk Kosinski]

Hi, are you seeing this behavior with isolated or shared networks?  I believe 
that is the expected behavior for an isolated network, whereas for shared 
networks the VLAN should be persistent. 

Best regards,


kirk.kosin...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HS
@shapeblue



-Original Message-
From: Venkat Boggarapu [mailto:venka...@axiomio.com] 
Sent: Tuesday, June 14, 2016 5:57 AM
To: users@cloudstack.apache.org
Subject: PERSISTANT VLANID FOR VIRTUAL MACHINE

Hi All,

Our present environment is CS4.3.1 and XENSERVER 6.2.

In Cloud Stack we will create a separate VLAN ID for each Virtual machine.

While doing maintenance or if we reboot the router for any reasons, the VLAN ID 
for the virtual machine changes.

My query is I want to keep the same VLAN ID if we reboot the router or do any 
maintenance.

I need PERSISTENT VLAN-ID for the Virtual Machine.

If any have faced this scenario please help me how to keep the VLAN-ID 
persistent for  virtual machine.


Thanks,
Venkat Boggarapu

PERSISTANT VLANID FOR VIRTUAL MACHINE

[Venkat Boggarapu]

Hi All,

Our present environment is CS4.3.1 and XENSERVER 6.2.

In Cloud Stack we will create a separate VLAN ID for each Virtual machine.

While doing maintenance or if we reboot the router for any reasons, the VLAN ID 
for the virtual machine changes.

My query is I want to keep the same VLAN ID if we reboot the router or do any 
maintenance.

I need PERSISTENT VLAN-ID for the Virtual Machine.

If any have faced this scenario please help me how to keep the VLAN-ID 
persistent for  virtual machine.


Thanks,
Venkat Boggarapu

Re: ACS 4.3 & VMware CPU Allocation

[Timothy Lothering]

Hello Community,

 

We have found a very interesting issue with CPU allocation in ACS 4.3 and
VMware. When a Service Offering is configured, you can choose the number of
Cores and clock speed, which is simple enough. The problem comes in on HOW
the cores are assigned.

 

In VMware at least, each core is assigned as a vSocket, with 1 vCore. As an
example:

 

1. Service Offering defined is 8 Cores @ 2.5GHz,

2. Instance is provisioned as 8 vSockets with 1vCore per Socket

3. OS displays all 8 "CPUs"

4. Happiness!

 

But, when you are using Core based licensing with products such as Microsoft
SQL 2014 Standard, there is a limit on the number of supported "physical"
sockets, in this case, 4.

 

So when you run a SQL query/command, only 4 of the 8 cores are used, the
only way around this is to change the VMware settings to 4x vSockets with 2x
vCores per socket. There is a performance hit as described here:
http://blogs.vmware.com/vsphere/2013/10/does-corespersocket-affect-performan
ce.html, but the main issue is that Customers are trying to use all
available resources.

 

My questions from the info above:

 

1. Will there be future support to define vSockets and vCores per
vSocket in a future release of ACS?

2. What is the impact on ACS Usage and Management reporting if we change
the vSockets manually? (on VMware itself)

 

Your insights would be appreciated.

 

Regards

 

Tim

 

Re: ACS 4.3 & VMware CPU Allocation

[Timothy Lothering]

Hello Community,

 

We have found a very interesting issue with CPU allocation in ACS 4.3 and
VMware. When a Service Offering is configured, you can choose the number of
Cores and clock speed, which is simple enough. The problem comes in on HOW
the cores are assigned.

 

In VMware at least, each core is assigned as a vSocket, with 1 vCore. As an
example:

 

1. Service Offering defined is 8 Cores @ 2.5GHz,

2. Instance is provisioned as 8 vSockets with 1vCore per Socket

3. OS displays all 8 "CPUs"

4. Happiness!

 

But, when you are using Core based licensing with products such as Microsoft
SQL 2014 Standard, there is a limit on the number of supported "physical"
sockets, in this case, 4.

 

So when you run a SQL query/command, only 4 of the 8 cores are used, the
only way around this is to change the VMware settings to 4x vSockets with 2x
vCores per socket. There is a performance hit as described here:
http://blogs.vmware.com/vsphere/2013/10/does-corespersocket-affect-performan
ce.html, but the main issue is that Customers are trying to use all
available resources.

 

My questions from the info above:

 

1. Will there be future support to define vSockets and vCores per
vSocket in a future release of ACS?

2. What is the impact on ACS Usage and Management reporting if we change
the vSockets manually? (on VMware itself)

 

Your insights would be appreciated.

 

Regards

 

Tim

 

Re: Best NIC for XenServer?

[Michael J McCafferty]

Stephan,
Thanks for your reply.
Yes, we run the storage network over the same bond. We are not using
the X540-AT2, we are using the X520-DA2. We are using SFP+, not RJ-45.
I'd rather use TwinAx cables or SFP+, as our switches are not RJ-45. So,
I'd prefer not to upgrade to those either. Is this was you are using? Am
I misunderstanding your statement?

The problems with the NICs are usually before any load it put on the
host... we never put load on the host because the the NIC is messed up
in some way. They seem to perform fine too. In an VM I can move 10.5Gbps
from a single VM to primary storage with a couple of simultaneous dd.
I just checked some historical metrics on the hosts that have had
recent issues with the NICs, and there are no event s where there was
high CPU or memory utilization in Dom0. I'll have to ask another person
on my team about OVS vs. Kernel.

Thanks!
Mike

On Tue, 2016-06-14 at 10:11 +0200, Stephan Seitz wrote:
> Hi,
> 
> XS 6.5 is built around CentOS 5 with a custom 3.10 Kernel. Using bonded
> X540-AT2 NIC, I can't see any problems.
> Depending on your network setup, your bond might be created and managed
> by OVS instead of Kernel.
> Just a guess, but OVS runs in userspace and could be affected by Dom0
> RAM shortage or heavy load.
> Do you run your storage network over the same bond?
> 
> On Mo, 2016-06-13 at 16:08 -0700, Michael J McCafferty wrote:
> > Fellow CloudStackers,
> > 
> > We are currently using Intel X520-DA2 NICs in our hosts. The
> > hosts use
> > XenServer. We have upgraded XenServer and applied periodic patches
> > and
> > updates to XenServer... in general done the usual maintenance. It
> > seems
> > that there are more issues with the NICs than expected. During
> > maintenance or after reboots, very irregularly, they may disappear,
> > lose
> > the bond, being detected but not be configured in Xen.
> > The HCL for XenServer 6.5 now lists the chip that is on the
> > NIC, but
> > not the NIC model it self. This leaves me to wonder WTF.
> > 
> > I have to ask, is there a known "best" NIC(s) to use with
> > XenServer
> > going forward? Do the Intel X520-DA2 model known to be finicky with
> > XenServer?
> > What is your experience?
> > 
> > Thanks!
> > Mike
> > 

-- 

Michael J. McCafferty
CEO
M5 Hosting
http://www.m5hosting.com

Like us on Facebook for updates and photos:
https://www.facebook.com/m5hosting

RE: XenServer nested on XenServer

[丸子良太 / MARUKO，RYOTA]

Hi, Paul

Thank you for your e-mail.
And I will write the details of my networking.

Please wait for my e-mail.
(English is too difficult for me(^^))

Regards


>-Original Message-
>From: Remi Bergsma [mailto:rberg...@schubergphilis.com]
>Sent: Tuesday, June 14, 2016 4:27 PM
>To: users@cloudstack.apache.org
>Subject: Re: XenServer nested on XenServer
>
>Hi Paul,
>
>I don’t get it but that’s probably me :-) Never mind.
>
>Regards,
>Remi
>
>On 13/06/16 16:00, "Paul Angus"  wrote:
>
>>Remi,
>>
>>I think asking for the details for Maruko San's networking in order to give 
>>him (hopefully) useful specific help covered
>that part.
>>
>>Haters gonna hate.
>>Paul Angus
>>
>>paul.an...@shapeblue.com
>>www.shapeblue.com
>>53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>>@shapeblue
>>
>>
>>
>>-Original Message-
>>From: Remi Bergsma [mailto:rberg...@schubergphilis.com]
>>Sent: 13 June 2016 14:26
>>To: users@cloudstack.apache.org
>>Subject: Re: XenServer nested on XenServer
>>
>>I kinda like shameless self-plugs although I fail to see how this one answers 
>>the question asked?
>>
>>On 13/06/16 14:09, "Paul Angus"  wrote:
>>
>>>Hi Maruko San
>>>
>>>We'd need to see the details of your networking.
>>>We've created Trillian   github.com/shapeblue/Trillian - it's based on ESXi 
>>>and uses CloudStack to orchestrate everything.
>>>
>>>
>>>
>>>Kind regards,
>>>
>>>Paul Angus
>>>
>>>paul.an...@shapeblue.com
>>>www.shapeblue.com
>>>53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>>>
>>>
>>>
>>>-Original Message-
>>>From: 丸子良太 / MARUKO，RYOTA [mailto:ryota.maruko...@hitachi-solutions.com]
>>>Sent: 13 June 2016 07:53
>>>To: users@cloudstack.apache.org
>>>Subject: XenServer nested on XenServer
>>>
>>>Hi
>>>
>>>I tried to create XenServer nested on XenServer for CloudStack.
>>>It is success to create XenServer nested on XenServer, And CloudStack 
>>>Manager create the system VMs.
>>>
>>>But VR could not access the user VMs.
>>>
>>>Please tell me about the problem.
>>>
>>>Regards
>>>
>>

RE: Can't stop mgmt server cleanly for CS 4.8.0

[Paul Angus]

Hi,


I filed a bug for this a while back: 
https://issues.apache.org/jira/browse/CLOUDSTACK-9227
If you have any further info, please add to the ticket - particularly if you 
find a fix :)




Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



-Original Message-
From: Marc-Andre Jutras [mailto:mar...@marcuspocus.com] 
Sent: 13 June 2016 14:20
To: users@cloudstack.apache.org
Subject: Re: Can't stop mgmt server cleanly for CS 4.8.0

try to upgrade your tomcat to ver 7...


On 2016-06-10 4:10 PM, Yiping Zhang wrote:
> RHEL 6.7 / java-1.7.0-openjdk-1.7.0.85-2.6.1.3 / tomcat6-6.0.24-90
>
> On 6/10/16, 12:49 PM, "Marc-Andre Jutras"  wrote:
>
>> which java / tomcat / centos version you're running on ?
>>
>>
>> On 2016-06-10 3:41 PM, Yiping Zhang wrote:
>>> Hi, all:
>>>
>>> We have a cron job to restart mgmt. service once a week. However, after we 
>>> upgraded to CS 4.8.0, the cron job would leave the service stopped and 
>>> Nagios starts to page oncall.  We traced the problem to that the mgmt. 
>>> service won’t stop cleanly, even when we try to stop it manually from CLI:
>>>
>>> # service cloudstack-management stop
>>> Stopping cloudstack-management:[FAILED]
>>> # service cloudstack-management status cloudstack-management dead 
>>> but pid file exists The pid file locates at 
>>> /var/run/cloudstack-management.pid and lock file at 
>>> /var/lock/subsys/cloudstack-management.
>>>   Starting cloudstack-management will take care of them or you can 
>>> manually clean up.
>>> #
>>>
>>> The catalina.out log file has following exception:
>>>
>>> INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] (Thread-95:null) 
>>> stopping bean ClusterManagerImpl INFO  [c.c.c.ClusterManagerImpl] 
>>> (Thread-95:null) Stopping Cluster manager, msid : 60274787591663 
>>> ERROR [c.c.c.ClusterServiceServletContainer] (Thread-11:null) 
>>> Unexpected exception
>>> java.net.SocketException: Socket closed
>>>at java.net.PlainSocketImpl.socketAccept(Native Method)
>>>at 
>>> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398)
>>>at java.net.ServerSocket.implAccept(ServerSocket.java:530)
>>>at java.net.ServerSocket.accept(ServerSocket.java:498)
>>>at 
>>> com.cloud.cluster.ClusterServiceServletContainer$ListenerThread.run(
>>> ClusterServiceServletContainer.java:131)
>>> log4j:WARN No appenders could be found for logger 
>>> (com.cloud.cluster.ClusterServiceServletContainer).
>>> log4j:WARN Please initialize the log4j system properly.
>>> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for 
>>> more info.
>>> Exception in thread "Timer-2" java.lang.NullPointerException
>>>at 
>>> org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:304)
>>>at 
>>> org.apache.cloudstack.managed.context.ManagedContextRunnable.getContext(ManagedContextRunnable.java:66)
>>>at 
>>> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
>>>at 
>>> org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27)
>>>at java.util.TimerThread.mainLoop(Timer.java:555)
>>>at java.util.TimerThread.run(Timer.java:505)
>>> Exception in thread "Timer-1" java.lang.NullPointerException
>>>at 
>>> org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:304)
>>>at 
>>> org.apache.cloudstack.managed.context.ManagedContextRunnable.getContext(ManagedContextRunnable.java:66)
>>>at 
>>> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
>>>at 
>>> org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27)
>>>at java.util.TimerThread.mainLoop(Timer.java:555)
>>>at java.util.TimerThread.run(Timer.java:505)
>>>
>>> The SocketException does not show up in every CS instances, but those 
>>> NullPointerException for thread Timer-1/2 are present for all CS instances.
>>>
>>> As a work around, we have to stop the service again, to clean up leftover 
>>> pid and lock files,  before starting the service again.
>>>
>>> Has anyone else seen this problem ?
>>>
>>> Thanks,
>>>
>>> Yiping

Re: Best NIC for XenServer?

[Stephan Seitz]

Hi,

XS 6.5 is built around CentOS 5 with a custom 3.10 Kernel. Using bonded
X540-AT2 NIC, I can't see any problems.
Depending on your network setup, your bond might be created and managed
by OVS instead of Kernel.
Just a guess, but OVS runs in userspace and could be affected by Dom0
RAM shortage or heavy load.
Do you run your storage network over the same bond?

On Mo, 2016-06-13 at 16:08 -0700, Michael J McCafferty wrote:
> Fellow CloudStackers,
> 
>   We are currently using Intel X520-DA2 NICs in our hosts. The
> hosts use
> XenServer. We have upgraded XenServer and applied periodic patches
> and
> updates to XenServer... in general done the usual maintenance. It
> seems
> that there are more issues with the NICs than expected. During
> maintenance or after reboots, very irregularly, they may disappear,
> lose
> the bond, being detected but not be configured in Xen.
>   The HCL for XenServer 6.5 now lists the chip that is on the
> NIC, but
> not the NIC model it self. This leaves me to wonder WTF.
> 
>   I have to ask, is there a known "best" NIC(s) to use with
> XenServer
> going forward? Do the Intel X520-DA2 model known to be finicky with
> XenServer?
>   What is your experience?
> 
> Thanks!
> Mike
> 

Re: XenServer nested on XenServer

[Remi Bergsma]

Hi Paul,

I don’t get it but that’s probably me :-) Never mind.

Regards,
Remi

On 13/06/16 16:00, "Paul Angus"  wrote:

>Remi,
>
>I think asking for the details for Maruko San's networking in order to give 
>him (hopefully) useful specific help covered that part.
>
>Haters gonna hate.
>Paul Angus
>
>paul.an...@shapeblue.com 
>www.shapeblue.com
>53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>@shapeblue
>
>
>
>-Original Message-
>From: Remi Bergsma [mailto:rberg...@schubergphilis.com] 
>Sent: 13 June 2016 14:26
>To: users@cloudstack.apache.org
>Subject: Re: XenServer nested on XenServer
>
>I kinda like shameless self-plugs although I fail to see how this one answers 
>the question asked?
>
>On 13/06/16 14:09, "Paul Angus"  wrote:
>
>>Hi Maruko San
>>
>>We'd need to see the details of your networking.  
>>We've created Trillian   github.com/shapeblue/Trillian - it's based on ESXi 
>>and uses CloudStack to orchestrate everything.
>>
>>
>>
>>Kind regards,
>>
>>Paul Angus
>>
>>paul.an...@shapeblue.com
>>www.shapeblue.com
>>53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>>
>>
>>
>>-Original Message-
>>From: 丸子良太 / MARUKO，RYOTA [mailto:ryota.maruko...@hitachi-solutions.com] 
>>Sent: 13 June 2016 07:53
>>To: users@cloudstack.apache.org
>>Subject: XenServer nested on XenServer
>>
>>Hi
>>
>>I tried to create XenServer nested on XenServer for CloudStack.
>>It is success to create XenServer nested on XenServer, And CloudStack Manager 
>>create the system VMs.
>>
>>But VR could not access the user VMs.
>>
>>Please tell me about the problem.
>>
>>Regards
>>
>