Oh, thank you for information. I will look into.
2014-02-01 Marcus :
> Oh yes, and storage overprovisioning doesn't currently work for KVM
> storage types, but it's a relatively simple fix:
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-5806
>
> On Sat, Feb 1, 2014 at 12:12 AM, Marcus wrote
Oh yes, and storage overprovisioning doesn't currently work for KVM
storage types, but it's a relatively simple fix:
https://issues.apache.org/jira/browse/CLOUDSTACK-5806
On Sat, Feb 1, 2014 at 12:12 AM, Marcus wrote:
> I don't think you'd have to change anything. Cloudstack (at least for
> acco
I don't think you'd have to change anything. Cloudstack (at least for
accounting purposes) considers all storage 'fat' and calculates
capacity per the disk offering size compared to total size of the
primary pool. Then you can add an overprovisioning factor to fit your
needs in the config options.
Hi,
In the copyObject method of AncientDataMotionStrategy, we have the
following code to select an EndPoint:
EndPoint ep = selector.select(srcForCopy, destData);
if (ep == null) {
String errMsg = "No remote endpoint to send command, check
if host or ssvm
Yes, preallocation=metadata creates a large file full of holes. and
maybe I need to modify storage consumption measuring method of
CloudStack to care this kind sparse file.
To satisfy my needs, just turning on preallocation=metadata by default
or making it configurable from agent.properties is eno
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17541/#review33384
---
there is no patch here
- daan Hoogland
On Jan. 30, 2014, 3:31 p.m
Ok, so not technically sparse in the sense that you have a large file
full of holes, but it's still not allocating the entire disk upfront.
You get the same result of disk savings either way, existing
cloudstack installs with qcow2 are still saving space in the same
manner.
On Fri, Jan 31, 2014 at
Here are my tests, using stock centos 6.5 qemu-img:
[root@server ~]# qemu-img create -f qcow2 image.qcow2 10G
Formatting 'image.qcow2', fmt=qcow2 size=10737418240 encryption=off
cluster_size=65536
[root@server ~]# qemu-img info image.qcow2
image: image.qcow2
file format: qcow2
virtual size: 10G (1
Yes, no_option.img is only 256k in size. it's sparse.
On Fri, Jan 31, 2014 at 11:38 PM, Yoshikazu Nojima wrote:
>>I don't think preallocation=metadata is required for sparse qcow2.
>>Just if you want it to NOT be sparse for metadata.
>
> I think it is required. Please see the output below. Only
>
>I don't think preallocation=metadata is required for sparse qcow2.
>Just if you want it to NOT be sparse for metadata.
I think it is required. Please see the output below. Only
"metadata.img" is a sparse file.
==
[root@ut1-qmb-rd5c test]# qemu-img create -f qcow2 -o
preallocation=off
I don't think there needs to be a lot of engineering around this, we
can probably just turn on preallocation=metadata by default.
If there are any other options/features you want to add (such as
preallocation=full), they can simply be turned on via agent.properties
and/or global/hypervisor/cluster
I don't think preallocation=metadata is required for sparse qcow2.
Just if you want it to NOT be sparse for metadata.
I also remember hearing that either recent qemu-img has a decent
preallocation by default now, or that performance has improved such
that it doesn't matter. Will need to do some re
I like the idea in principal. We should fail as fast as is practical.
I wonder, are you just checking if the resources are available? If so, it's
still possible for deployVM to fail even if this check said all was good
because the state of the system could change before the actual deployVM is
star
Hello Nux,
Thank you for your comment. I will prepare feature specification.
Regards,
2014-01-31 Nux! :
> On 31.01.2014 20:24, Yoshikazu Nojima wrote:
>>
>> Afternoon All,
>>
>> Is there anyone working on adding volume provisioning method option?
>> As you know, thin provisioning of a volume sav
Makes lot of sense. Would the same API allow the caller just to check (not
actually proceed to create) whether resources are present for a particular
payload? This may be useful for the client who want to proactively check and
avoid returning failure.
Are there any race condition possibilities
Currently there is no way to know if there is enough resources for vm
deployment, before actual deployVm call is made. The sequence is the following:
1) Deploy Vm is called
2) DB record is created for the Vm
3) Storage/Host allocators determine whethere there are enough resources for vm
to be de
Thanks Erik.
Management sever is with jre 1.6; I will upgrade MS machine with jre 1.7 and
try.
Regards,
Rayees
-Original Message-
From: Erik Weber [mailto:terbol...@gmail.com]
Sent: Friday, January 31, 2014 1:38 PM
To: dev@cloudstack.apache.org
Subject: Re: Management server failed t
On Fri, Jan 31, 2014 at 10:29 PM, Rayees Namathponnan <
rayees.namathpon...@citrix.com> wrote:
> Hi All,
>
> Management server failed to start with latest master, observed below
> error; anyone faced this issue?
>
>
> java.lang.UnsupportedClassVersionError:
> org/apache/cloudstack/spring/module/we
Thanks, Tim!
Do you know of a good doc on the web I can view to see specifically what
these numbers mean (like what they include and don't include)?
On Fri, Jan 31, 2014 at 2:29 PM, Tim Mackey wrote:
> Mike, I've confirmed that the data items map as you suspected to XenCenter.
> In this case
Hi All,
Management server failed to start with latest master, observed below error;
anyone faced this issue?
INFO:
validateJarFile(/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/servlet-api-2.5-20081211.jar)
- jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
Mike, I've confirmed that the data items map as you suspected to XenCenter.
In this case the values had a rounding effect just on either side of 20.05
respectively to create the observed numbers.
On Thu, Jan 30, 2014 at 6:37 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> Great - th
Interesting that destroying the VMs and letting them be re-created does not
solve the problem.
If I destroy my cloud and start over from scratch, though, that fixes it
all.
On Fri, Jan 31, 2014 at 1:55 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> If I do a CTRL-D (as the console
On 31.01.2014 20:24, Yoshikazu Nojima wrote:
Afternoon All,
Is there anyone working on adding volume provisioning method option?
As you know, thin provisioning of a volume save consumption of a
storage, and fat provisioning improves IOPS performance.
Especially, Qcow2 can save storage consumptio
If I do a CTRL-D (as the console says I can do), the VM boots up; however,
the agent does not show as "Up" in the GUI (for either SSVM or CPVM).
I noticed this problem again today.
My system VMs were running fine yesterday. I decided to reboot them to see
if this problem still existed and it did. None of the system VMs reboot
properly:
http://i.imgur.com/dLHf37W.png
On Tue, Jan 28, 2014 at 3:20 PM, Mike Tutkowski <
mike.tutkow...@solidf
Afternoon All,
Is there anyone working on adding volume provisioning method option?
As you know, thin provisioning of a volume save consumption of a
storage, and fat provisioning improves IOPS performance.
Especially, Qcow2 can save storage consumption and achive relatively
better performance than
Build-api.sh looks likes it needs 3 arguments
TARGETJARDIR
DEPSDIR
DISTDIR
I tried
"/usr/local/cloudstack/engine/service/target/engine/WEB-INF/lib"
"/usr/local/cloudstack/agent/target/dependencies"
And
"/usr/local/cloudstack/dist"
I think at least my DISTDIR is wrong
Can someone tell me what t
I have got past the install issue. However, when I am trying to add a KVM host
to the management server, I see following message in the management-server.log:
——
2014-01-31 01:15:42,895 DEBUG [c.c.u.s.SSHCmdHelper]
(catalina-exec-5:ctx-1569065b ctx-65347efa) cloudstack-setup-agent -m
10.84.13.
I finally got the packer built devcloud box to boot with vagrant, but
running 'xe vm-list' in it results in:
Error: Connection refused (calling connect )
I'm going to do some more investigation, but could take a while as I
get to learn xen.
To make things easy while working on this I've created
Team,
1. It seems the simulator-gate project in that view, was not able to fetch the
code using jenkins git plugin and is stuck as per below message. This job is
failing continuously with no use as of now.
2. If possible, can i get the access to simulator node? Currently, i don't have
access t
Just continuing this for my own learning experience as I still don't see
it. I also don't see why the outputs from the commited code are OK, on
testing I'm getting things like: [55, 107, 73, 50, 87, 100, 119, 49, 121,
76, 56, 43, 104, 48, 112, 105, 107, 102, 111, 88, 87, 73, 98, 113, 120, 52,
85, 6
+1 voted.
Example use case: Our customer portal should actually be able to do a
'listclusters showcapacities=true', to inform our customers on their privately
owned private zones, which are controlled by our CloudStack environment.
At this stage, I can only give a root-level API/Secret key comb
Hey guys, I only saw this thread just now. I have reverted the change
in 4.3-forward and redid only the highest prio-parts in separate
commits.
@Animesh you should have a mail wiith the list of new commits
@Alena I'll revisit the part in UserVmJoinVO to see what if anything
is needed to satisfy th
Well guys, yesterday I took a look at the CS source code and how it was
getting those values. I think that I cracked it.
It seems that there is a whole misunderstanding about the used memory value
and It would be nice an update on the Cloudstack API documentation.
Let's start:
Here is a link for
Sanjay,
Yep, I understand that the bug was for resource count for secondary
storage, but the causes and errors are similar to what I see for primary
storage.
Here are the information you requested.
{u'account': [{u'accounttype': 0,
u'cpuavailable': u'Unlimited',
I’m curious if there is any interest in creating a “SDK” for developing plugins
in CloudStack. Right now, to develop my plugin, I need a development
environment set up in order to have the maven artifacts required for compiling
against. This can end up being quite a bit of work to maintain if yo
Just did:
https://issues.apache.org/jira/browse/CLOUDSTACK-6004
I put it as a blocker because it breaks the ability to do proper server
maintenance without downtime.
Thanks for looking into this. Like I said, it's possible it's fixed in
4.3, but I am not equipped to test right now.
Francois
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17591/
---
Review request for cloudstack.
Bugs: CLOUDSTACK-5872
https://issues.apache.
I encountered the GIT plugin timeout as well on simulator slaves,
thanks for taking care of all these problems, appreciate it!
On Wed, Jan 29, 2014 at 09:09:05AM +0100, Hugo Trippaers wrote:
> Hey guys,
>
> Ofter the last few weeks we had a lot of problems with Jenkins
> actually reporting build
tehre is a ticket CLOUDSTACK-5920
not much activity on it yet. It does however mention the buzzword rbac
which would point in the direction of Eriks whishes and our own.
vote vote vote please
On Fri, Jan 31, 2014 at 12:47 PM, Alex Hitchins
wrote:
> Agreed - I believe the IAM proposal that went
Agreed - I believe the IAM proposal that went out recently may have covered
this topic a little too.
Is it something to bake into the API layer or better/cleaner to build some
proxy layer that handles permissions?
Alex Hitchins
+44 7788 423 969
-Original Message-
From: Erik Weber [ma
On Fri, Jan 31, 2014 at 12:00 PM, Daan Hoogland wrote:
> H,
>
> I git a question of an operator ad Schuberg Philis to crete a set of
> api keys and to have control over excatly what api calls are allowed
> for this set of keys. Does anybody else recognise this use case?
> already hacked it in? hav
H,
I git a question of an operator ad Schuberg Philis to crete a set of
api keys and to have control over excatly what api calls are allowed
for this set of keys. Does anybody else recognise this use case?
already hacked it in? have an idea how to do it? has a reason why not
to do it?
regards,
Da
> On Jan. 31, 2014, 10:20 a.m., daan Hoogland wrote:
> > ported to master and committed: fc796632ed984f37fdf32e6aedf26d179a70b22f
62a259ffa9b4daabcbe4f9afe9a78eadebbb7bff on 4.3-forward
- daan
---
This is an automatically generated e-ma
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15280/#review33309
---
Commit 62a259ffa9b4daabcbe4f9afe9a78eadebbb7bff in branch
refs/head
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15280/#review33308
---
Ship it!
ported to master and committed: fc796632ed984f37fdf32e6aed
Oh great! Yes, 4.4 is the current master.
>-Original Message-
>From: Jeff Hair [mailto:j...@greenqloud.com]
>Sent: Friday, January 31, 2014 3:16 PM
>To: dev@cloudstack.apache.org
>Subject: Re: EC2 Rest Servlet "domain cannot be null!!" Error In Advanced
>Networking Mode
>
>Hi Likitha,
>
>T
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17586/
---
Review request for cloudstack and Sebastien Goasguen.
Repository: cloudstack-gi
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17586/
---
(Updated Jan. 31, 2014, 9:51 a.m.)
Review request for cloudstack and Sebastien
Hi Likitha,
The fix you committed is actually the exact same way we wound up fixing it,
although we put ours on the mirror of the 4.2.1 branch that we have. Since
you said the EC2 REST/SOAP API hasn't been well-tested in advanced mode
networking, we may run into more issues like this. If we do, an
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16385/#review33306
---
Mandar, still feel like picking this up. As Nithin didn't reply anym
Heya,
I just pulled the commits by Abhinandan Prateek into master. With the switch to
java 7 on master we need ire 7 in the systemvms. If you are testing with master
be sure to download the latest systemvm builds (after commit id
d578d7ef85a7304aec18a207a35535f62eed0e0b). Otherwise starting the
On Fri, Jan 31, 2014 at 7:46 AM, Girish Shilamkar wrote:
> Hello,
>
> In ACS KVM the volumes attached are seen as normal disk /dev/vda /dev/vdb
> and so on. But with vmware it seems Volume Groups are being used.
> The root device is /dev/mapper/VolGroup00-LogVol100 which previously it
> was /dev/h
H Animesh,
You have reverted my findbugs fixes in
f4db8df66fbcb5df3cd9bbf607ede9a4d514fe4a
Quite justly so, no doubt. However in my overeagerness I combined a
lot of things in that change. Some of those findbugs considdered in
the scariest category. I have made new commits, one per file. These
ar
54 matches
Mail list logo
