4 scripts need to be recopy on all XenServer that have been patches. [1]
section 5.4
[1]
http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/latest/hypervisor/xenserver.html#upgrading-xenserver-versions
PL
On Wed, Dec 31, 2014 at 3:09 PM, Somesh Naidu
wrote:
> Could you try
Could you try restarting CS or unmange/mange the XS cluster to see if that
fixes the issue.
As an aside, one bad thing about this error is that most times it doesn’t
explicitly say why the zone is not ready so we have to deduce. Following are
few of the reasons why this could happen:
1. Storage
You mean the system VMs for Zone 1 are running? Are they showing as connected
in the DB?
If they are, can you stop these VMs and see if they start okay.
From: Mohamed Infaz [infaz...@cse.mrt.ac.lk]
Sent: Tuesday, December 30, 2014 21:26
To: users@cloudstac
I believe this is an issue with NUMA. I think this is only a display issue and
not actually causing any capacity issues.
We have this output from virsh nodeinfo on two identical hosts:
CPU model: x86_64
CPU(s): 16
CPU frequency: 1600 MHz
CPU socket(s): 2 <--
Cor
> 2014-12-31 07:49:44,405 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (Job-Executor-22:ctx-f2bc1611 ctx-77cccfb5) No suitable pools found
> 2014-12-31 07:49:44,405 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (Job-Executor-22:ctx-f2bc1611 ctx-77cccfb5) No suitable storagePools found
> under t
The log on mgmt is:
***
2014-12-31 07:49:44,138 DEBUG [c.c.a.ApiServlet] (catalina-exec-2:ctx-de733770)
===START=== 172.30.1.107 -- GET
command=deployVirtualMachine&response=json&sessionkey=ExqHTfNe1JVXnQXRkEpgjMoDqu0%3D&zoneid=80b7c240-9204-43eb-85c8-762c7d7f6a15&templateid=449e34
Hello,
The obvious question - is your host HVM capable?
I think it needs to be since it might be required to run system VMs.
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
- Original Message -
> From: "Mitch.Fiorentini"
> To: users@cloudstack.apache.org
Yes, I'm also seeing this on DELL PE R720... It seems like a libvirt fail, try
to submit a bug upstream (redhat bugzilla).
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
- Original Message -
> From: "Abdul Rasool"
> To: users@cloudstack.apache.org
> Sent
(Note for anyone remotely interested in this later, it’s actually an array
returned, not a hash. My mistake.)
On 12/31/14, 2:28 AM, "Ian Forde" wrote:
>Hi Rohit,
>
>From a bash perspective (since I started down this path from cloudmonkey),
>I think that’s a very strange feature, to be honest.
Hi Rohit,
From a bash perspective (since I started down this path from cloudmonkey),
I think that’s a very strange feature, to be honest. That would mean that
any search for an object’s id would have to filter API call results for an
exact match to the name. Example:
Existing objects:
zone: z
Hi Ian,
Now I understand your issue. Yes, the name parameter does not search for exact
cluster matching the “name” you pass but for any cluster name that matches for
the substring “ster1”.
In short, it’s not a bug, but feature - searches for resource names matching a
passed substring.
> On 31
Note that “ster1” is a proper substring match with “cluster1”. I tested
it again on both 4.3.1 (RPMs on RHEL) and 4.4.2 (RPMs on CentOS) and got
the same results.
Also tried (in Cloudmonkey) “api listClusters name=ster1” and got a match
on both 4.3.1 and 4.4.2.
I also tried the CLI method. Doin
Which version of CloudStack you’re on? On 4.3.1/4.3.2, if I list clusters with
a name that does not exist I get no results. Tested with both CloudMonkey 5.3.0
and 5.3.1 (voting candidate, since 5.3.1 has not been released yet).
If you run raw API in say browser, with and without the name arg do
13 matches
Mail list logo
