We have such a weird way of storing storage tags in the DB.
They get stored as individual rows in the storage_pool_details table (which
is fine). If the value in the value column is true, then we assume the
key column contains the name of a storage tag.
This makes it more difficult than it
Github user asfgit closed the pull request at:
https://github.com/apache/cloudstack/pull/79
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
I agree...and understand :)
But would this means, that VMs will not be provisioned anywhere during HA
kicking in ? I guess so...
So I avoid having started another copy of the same VM, that is alrady
running on disconnected hosts - I need this as the temporary solution,
during CEPH backfilling, so
Hey Ian,
Since it looks like the intent of this particular thread is just to discuss
RBD and snapshots (which I don't think your business uses), you would be
more interested in the Query on snapshot and cloning for managed storage
thread as that one talks about this issue at a more general level.
Seems to me, that I'm about to issue something similar to: update
cloud.vm_instance set ha = 0 where ha =1...
Now seriously, wondering, per the manual - if you define HA host tag on the
global config level, and then have NO hosts with that tag - MGMT will not
be able to start VMs on other
Hi Andrija,
The way I understand it (and have seen in practice) is that by default
the MGMT server will use any available server for HA. Setting the HA
tag on a hosts just dedicates that host to HA, meaning that during
normal provisioning no VMs will use that host, it will only be used
for HA
I have been working on this on and off for a while now (as time permits).
Here is an e-mail I sent to a customer of ours that helps describe some of
the issues:
*** Beginning of e-mail ***
The main requests were around the following features:
* The ability to leverage SolidFire snapshots.
*
I should have also commented on KVM (since that was the hypervisor called
out in the initial e-mail).
In my situation, most of my customers use XenServer and/or ESXi, so KVM has
received the fewest of my cycles with regards to those three hypervisors.
KVM, though, is actually the simplest
Hi Mike,
I think the interest in this issue is primarily for Ceph RBD, which
doesn't use iSCSI or SAN concepts in general. As well I believe RBD
is only currently supported in KVM (and VMware?). QEMU has native RBD
support, so it attaches the devices directly to the VMs in question.
It also
Hi Mike,
I agree it is a general CloudStack issue that can be addressed across
multiple primary storage options. It's a two stage issue since some
changes will need to be implemented to support these features across
the board, and others will need to be made to each storage option.
It would be
Agree with Logan. As fans of Ceph as well as SolidFire, we are interested
in seeing this particular use case (RBD/KVM) being well implemented,
however the concept of volume snapshots residing only on primary storage vs
being transferred to secondary storage is a more generally useful one that
is
Hi,
Quick question, using the API, how would a user remove an associated SSH
keys to an instance? What call should we use? Seems that you can't based
on the existing API calls.
Furthermore, how can we change the SSH Key? Is it the
resetSSHKeyForVirtualMachine call?
Thanks.
--
Francois
yes?
https://cloudstack.apache.org/docs/api/apidocs-4.4/user/resetSSHKeyForVirtualMachine.html
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
- Original Message -
From: Francois Gaudreault fgaudrea...@cloudops.com
To: dev@cloudstack.apache.org
Sent: Monday,
Whatever way you think makes the most sense.
Either way, I'm working on this for XenServer and ESXi (eventually on KVM,
I expect) for managed storage (SolidFire is an example of managed storage).
On Mon, Feb 16, 2015 at 2:38 PM, Andrei Mikhailovsky and...@arhont.com
wrote:
I am happy to see
Yes what? That API call is not clear at all.
I guess a try it yourself is what you meant?
Thanks for your great help.
FG
On Feb 16, 2015 5:04 PM, Nux! n...@li.nux.ro wrote:
yes?
https://cloudstack.apache.org/docs/api/apidocs-4.4/user/resetSSHKeyForVirtualMachine.html
--
Sent from the
Look...I apologize for the sarcasm. I was a little bit irritated. I just
wanted to get some help.
I read the API documentation, I read the User guide. I just wanted to
same some time and ask on this list.
Thanks.
FG
On 2015-02-16 5:04 PM, Nux! wrote:
yes?
Depending on what you actually want to achieve, you could also register a bogus
public key and reset to that one, knowing it will never really work.
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
- Original Message -
From: Francois Gaudreault
Hi all,
I have been some tests on the branch in order to give you all some confidence.
During the tests I found 1 bug related to communication from VM A on Tier 1 to
VM B on Tier 2 in a Single VPC. I can reproduce the bug and it disappears when
I convert the Single VPC to a redundant one. I
Thanks for looking at it and testing it.
That answers the key replacement. Looks like there is no way to actually
removing the key from a created VM. I believe the only way left is the
deletion. The updateVM call won't update it either :S
FG
On 2015-02-16 6:37 PM, Nux! wrote:
BIG +1
My team should submit some patch to ACS for better KVM snapshots, including
whole VM snapshot etc...but it's too early to give details...
best
On 16 February 2015 at 13:01, Andrei Mikhailovsky and...@arhont.com wrote:
Hello guys,
I was hoping to have some feedback from the community
After digging a bit further and getting hints from Rohit, the correct syntax to
achieve this without using any additional scripting would be:
list volumes tags[0].key=remote_backup tags[0].value=yes
This will only list the volumes with the tag remote_backup=yes
Thanks for your help and
I had similar issues at least two or thee times. The host agent would
disconnect from the management server. The agent would not connect back to the
management server without manual intervention, however, it would happily
continue running the vms. The management server would initiate the HA and
Ilya
Thanks a lot ! I try to read the source code.
Best Regards,
Star Guo
-邮件原件-
发件人: ilya musayev [mailto:ilya.mailing.li...@gmail.com]
发送时间: 2015年2月15日 15:00
收件人: dev@cloudstack.apache.org
主题: Re: Ans: About Instance Storage Live Migration on VMware
Star,
There is an API call
Well...count me in on the general-purpose part (I'm already working on that
and have much of it working).
If someone is interested in implementing the RBD part, he/she can sync with
me and see if there is any overlapping work that I've already implementing
from a general-purpose standpoint.
On
I am happy to see the discussion is taking its pace and a lot of people tend to
agree that we should address this area. I have done the ticket for that, but I
am not sure if this should be dealt in a more general way as suggested. Or
perhaps having individual tickets for each hypervisor would
+1 for renaming the Snapshot into something more logical.
However, for many ppl Backups kind of means the functionality on a more
granular level (like ability to restore files, etc.) Not sure if Backup should
be the right term for the current volume Snapshots.
I agree, there should be
Totally agreed that there is high value in having both the ability to do
rapid, lightweight snapshots on primary storage as well as the ability to
transfer those snapshots to secondary storage for highly durable long-term
use, template creation etc... Glad to hear that others see a distinction
On 16-02-15 13:16, Andrei Mikhailovsky wrote:
I had similar issues at least two or thee times. The host agent would
disconnect from the management server. The agent would not connect back to
the management server without manual intervention, however, it would happily
continue running the
I like this idea a lot for Ceph RBD. I do think there should still be
support for copying snapshots to secondary storage as needed (for
transfers between zones, etc.). I really think that this could be
part of a larger move to clarify the naming conventions used for disk
operations. Currently
On 16-02-15 15:38, Logan Barfield wrote:
I like this idea a lot for Ceph RBD. I do think there should still be
support for copying snapshots to secondary storage as needed (for
transfers between zones, etc.). I really think that this could be
part of a larger move to clarify the naming
GitHub user wilderrodrigues opened a pull request:
https://github.com/apache/cloudstack/pull/78
Feature/systemvm persistent config 4
Hi Daan,
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/schubergphilis/cloudstack
Github user wilderrodrigues closed the pull request at:
https://github.com/apache/cloudstack/pull/78
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user wilderrodrigues commented on the pull request:
https://github.com/apache/cloudstack/pull/78#issuecomment-74522767
It seems I made a mistake with the branch. Will close this one and create a
new PR.
Cheers,
Wilder
---
If your project is set up for it, you can
I'm just going to stick with the qemu-img option change for RBD for
now (which should cut snapshot time down drastically), and look
forward to this in the future. I'd be happy to help get this moving,
but I'm not enough of a developer to lead the charge.
As far as renaming goes, I agree that
GitHub user wilderrodrigues opened a pull request:
https://github.com/apache/cloudstack/pull/79
Latest changes on feature/systemvm persistent config
@DaanHoogland
Latest commits on this branch. Could you please have a look at this pull
request?
I will execute all the
Some sort of fencing independent of the management server is
definitely needed. HA in general (particularly on KVM) is all kinds
of unpredictable/buggy right now.
I like the idea of having a switch that an admin can flip to stop HA.
In fact I think a better job control system in general (e.g.,
Hello everyone,
I am trying to understand a couple of things but since I am not a Java
developer I need your help .
1. How are the jobids generated ? Based on what ?
I presume that after a new job is spawned and a new id generated, that goes
in the database .
I also assume that if you have
Github user bhaisaab closed the pull request at:
https://github.com/apache/cloudstack/pull/48
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Ladies gents,
Interoute is looking for a top-notch Cloudstack developer to join our rapidly
expanding team in London. More details here -
http://www.interoutejobs.com/vacancies/vacancy-cloudstack-development-architect-411928-31.html
, feel free to drop me a line directly if I can help with
H,
This is a pre-announcement;) I want to rebase our code this week and
then merge into master. This code is functionally tested against xen.
It is bound to be less perfect in other peoples environments so please
test if you have doubts. We (Wilder, Ian, me) will support after the
merge but let's
Github user asfgit closed the pull request at:
https://github.com/apache/cloudstack/pull/77
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
On 16-02-15 11:00, Andrija Panic wrote:
Hi team,
I just had funny behaviour few days ago - one of my hosts was under heavy
load (some disk/network load) and it went disconnected from MGMT server.
Then MGMT server stared doing HA thing, but without being able to make sure
that the VMs on
Hello guys,
I was hoping to have some feedback from the community on the subject of having
an ability to keep snapshots on the primary storage where it is supported by
the storage backend.
The idea behind this functionality is to improve how snapshots are currently
handled on KVM
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31081/
---
Review request for cloudstack and SrikanteswaraRao Talluri.
Bugs:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30660/#review72610
---
This is pending for review.
- Gaurav Aradhye
On Feb. 5, 2015,
45 matches
Mail list logo
