cloudshell for individual users

2019-03-19 Thread Richard Persaud
Hello, How can I enable a "cloudshell" instance for each account/user so they are able to manage their VPCs via the CLI? It would be great to offer a cloudMonkey cloudshell instance - similar to how Azure and GCP offer CLI options. Regards, Richard Persaud

Re: Disaster after maintenance

2019-03-19 Thread Sergey Levitskiy
select * from networks where removed is null; select * from vm_instance where id=87; select id,name from vm_instance where name like 'r%' and removed is null; Basically since the network offering is not redundant this error is only thrown when there is no router associated with your network. Usua

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
Check network_offering table for value in column redundant_router_service for the network offering you use. in table network_offering_table all records have redundant_router_service = 0 Can you also run the following: >>>select name, state, removed from host where name like 'r%' returns zer

Re: Disaster after maintenance

2019-03-19 Thread Sergey Levitskiy
Check network_offering table for value in column redundant_router_service for the network offering you use. Can you also run the following: select name, state, removed from host where name like 'r%' select * from domain_router; select * from router_network_ref; Cloudstack is supposed to recrea

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
>>>Network offering needs to be change to non-redundant How do I do that? On Tue, Mar 19, 2019 at 11:47 PM Sergey Levitskiy wrote: > Network offering needs to be change to non-redundant. Most likely old bug > is resurfaced. > https://issues.apache.org/jira/browse/CLOUDSTACK-9024 > > > > On 3/19

Re: Disaster after maintenance

2019-03-19 Thread Sergey Levitskiy
Network offering needs to be change to non-redundant. Most likely old bug is resurfaced. https://issues.apache.org/jira/browse/CLOUDSTACK-9024 On 3/19/19, 2:19 PM, "Jevgeni Zolotarjov" wrote: Hello I did exactly like you suggested. After UPDATE on db, I can see the rout

[RESULT][VOTE] Apache CloudStack 4.12.0.0

2019-03-19 Thread Gabriel Beims Bräscher
Hi all, After 3 business days, the vote for CloudStack 4.12.0.0 *passes* with 4 PMC + 2 non-PMC votes. +1 (PMC / binding) * Wido den Hollander * Simon Weller * Rafael Weingärtner * Rohit Yadav +1 (nonbinding) * Gabriel Bräscher * Nicolas Vazquez 0 none -1 none Thanks to everyone participating

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
Hello I did exactly like you suggested. After UPDATE on db, I can see the router in cloudstack console. But attempt to restart network fails. I get error: Resource [DataCenter:1] is unreachable: Can't find all necessary running routers! I rechecked agents on both servers. They look running OK.

Re: Disaster after maintenance

2019-03-19 Thread Andrija Panic
Ok, so: 1.BACKUP YOUR DB - in case there is issues, you will want to restore 2. I tried to reproduce your case on 4.11.2 (though didn't do any maintenance etc.) - and could not - I have artificially marked existing VR as removed in DB - and tried to restart network and it worked just fine. Let's

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
Yes. Just a single network. On Tue, 19 Mar 2019, 21:39 Andrija Panic, wrote: > Just one more clarification - this is Isolate single network (not Shared > Network, not VPC) ? > > > > On Tue, Mar 19, 2019, 19:36 Jevgeni Zolotarjov > wrote: > > > Name defaultGuestNetwork > > ID 4ba834ed-48f3-468f

Re: Disaster after maintenance

2019-03-19 Thread Andrija Panic
Just one more clarification - this is Isolate single network (not Shared Network, not VPC) ? On Tue, Mar 19, 2019, 19:36 Jevgeni Zolotarjov wrote: > Name defaultGuestNetwork > ID 4ba834ed-48f3-468f-b667-9bb2d2c258f1 > Zone PBT zone 1 > Description defaultGuestNetwork > Type Shared > State Setu

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
Name defaultGuestNetwork ID 4ba834ed-48f3-468f-b667-9bb2d2c258f1 Zone PBT zone 1 Description defaultGuestNetwork Type Shared State Setup VPC ID N/A Persistent No On Tue, Mar 19, 2019 at 8:29 PM Andrija Panic wrote: > Share the network id and name as seen from GUI... > > On Tue, Mar 19, 2019, 19:

Re: Disaster after maintenance

2019-03-19 Thread Andrija Panic
Share the network id and name as seen from GUI... On Tue, Mar 19, 2019, 19:27 Jevgeni Zolotarjov wrote: > >>> 1. Confirm please rolling restart is set to false please - double check > Double checked - It is set to false > > 2. If so - do you know the name of VR which you deleted ? Is it last

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
>>> 1. Confirm please rolling restart is set to false please - double check Double checked - It is set to false 2. If so - do you know the name of VR which you deleted ? Is it last one >>> ever created - if so we can find it easily... I dont know the name Is there a way to fetch it from DB? O

Re: Disaster after maintenance

2019-03-19 Thread Andrija Panic
Right...still complaining on missing running routers. 1. Confirm please rolling restart is set to false please - double check 2. If so - do you know the name of VR which you deleted ? Is it last one ever created - if so we can find it easily... On Tue, Mar 19, 2019, 18:40 Jevgeni Zolotarjov wr

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
Here is management server log https://drive.google.com/open?id=1H2jI0roeiWxtzReB8qV6QxDkNpaki99A On Tue, Mar 19, 2019 at 7:29 PM Andrija Panic wrote: > I would also try to "undelete" VR in DB, but let's keep this as last step. > > On Tue, Mar 19, 2019, 18:24 Andrija Panic wrote: > > > Disclaim

Re: Disaster after maintenance

2019-03-19 Thread Andrija Panic
I would also try to "undelete" VR in DB, but let's keep this as last step. On Tue, Mar 19, 2019, 18:24 Andrija Panic wrote: > Disclaimer: from mobile device. > > I don't see any special failure in agent log, except some long running > migration, timeout for graceful VM shutdown etc (and agent re

Re: Disaster after maintenance

2019-03-19 Thread Andrija Panic
Disclaimer: from mobile device. I don't see any special failure in agent log, except some long running migration, timeout for graceful VM shutdown etc (and agent restart) You did not send mgmt log after last network restart failure ? On Tue, Mar 19, 2019, 17:29 Jevgeni Zolotarjov wrote: > Unde

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
Under Infrastructure / Hosts: both hosts are enabled and green (Unsecure though) agent.log - https://drive.google.com/open?id=1rATxHKqgNKo2kD23BtlrZy_9gFXC-Bq- I set network.rolling.restart to false now. Restarted management server - same problem - cannot restart not delete network On Tue, Mar

Re: Disaster after maintenance

2019-03-19 Thread Andrija Panic
+1 on what Paul said - set that to false, restart mgmt and try network restart again. On Tue, Mar 19, 2019, 16:48 Boris Stoyanov wrote: > Hi, you shouldn’t be worried about data as long as you use a separate > shared storage. > > What does the cloudstack console say about your host? Is it up? If

Re: Disaster after maintenance

2019-03-19 Thread Boris Stoyanov
Hi, you shouldn’t be worried about data as long as you use a separate shared storage. What does the cloudstack console say about your host? Is it up? If it’s up then you should be able to deploy a VM on it. If not, you’ll need to investigate the reason cloudstack-agent is not connected, is t

RE: Disaster after maintenance

2019-03-19 Thread Paul Angus
Somewhere in your error, I think that I saw a reference to rolling reboot. Try disabling that in the global settings. ( network.rolling.restart ) paul.an...@shapeblue.com  www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue -Original Message- From: Jevgeni

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
Guys, please help with it. What can be done here? There is too much valuable data. On Tue, Mar 19, 2019 at 4:21 PM Jevgeni Zolotarjov wrote: > Tried that just now and got error: > Resource [DataCenter:1] is unreachable: Can't find all necessary running > routers! > > In the log I see: >

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
Tried that just now and got error: Resource [DataCenter:1] is unreachable: Can't find all necessary running routers! In the log I see: = 2019-03-19 14:20:39,644 DEBUG [o.a.c.e.o.NetworkOrchestrator] (API-Job-Executor-4:ctx-7b6b69eb job-5093 ctx-9be30648

RE: Disaster after maintenance

2019-03-19 Thread Andrija Panic
​​ Your network can't be deleted due to "Can't delete the network, not all user vms are expunged. Vm VM[User|i-2-11-VM] is in Stopped state" - which is fine. You should be able to just start the user VM - but if you have actually delete the VR itself, then just do Network restart with "cleanup"

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
I mean I cannot delete network: In the management server log I see == 019-03-19 14:06:36,316 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-1:ctx-1c0fd4dc job-5090) (logid:c734edfc) Executing AsyncJobVO {id:5090, userId: 2, account

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
I've managed to make libvirtd running Now cloudstack console shows both hosts - running But now as I have removed network, VMs are unable to start. How can I recreate the network now? On Tue, Mar 19, 2019 at 3:14 PM Ivan Kudryavtsev wrote: > Jevgeniy, it may be a documentation bug. Take s look

RE: Disaster after maintenance

2019-03-19 Thread Paul Angus
Libvirtd has its own logs, so you'll need to look at those I'm afraid. paul.an...@shapeblue.com  www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue -Original Message- From: Jevgeni Zolotarjov Sent: 19 March 2019 15:09 To: users@cloudstack.apache.org Subj

Re: Disaster after maintenance

2019-03-19 Thread Ivan Kudryavtsev
Jevgeniy, it may be a documentation bug. Take s look: https://github.com/apache/cloudstack-documentation/pull/27/files вт, 19 мар. 2019 г., 9:09 Jevgeni Zolotarjov : > That's it - libvirtd failed to start on second host. > Tried restarting, but it does not start. > > > >> Do you have some NUMA co

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
That's it - libvirtd failed to start on second host. Tried restarting, but it does not start. >> Do you have some NUMA constraints or anything which requires particular RAM configuration? No libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; en

RE: Disaster after maintenance

2019-03-19 Thread Paul Angus
Can you check that the cloudstack agent is running on the host and the agent logs (usual logs directory) Also worth checking that libvirt has started ok. Do you have some NUMA constraints or anything which requires particular RAM configuration? paul.an...@shapeblue.com  www.shapeblue.com Amadeu

Re: Disaster after maintenance

2019-03-19 Thread Rafael Weingärtner
that is why nothing deploys there. You need to connect this host to ACS. otherwise, it will just be ignored. Did you check the log files in the agent (in the host)? And, of course, in ACS? On Tue, Mar 19, 2019 at 9:49 AM Jevgeni Zolotarjov wrote: > Can you try migrating a VM to the server that y

Re: Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
Can you try migrating a VM to the server that you changed the RAM amount? Also: What is the hypervisor version? KVM QEMU Version : 2.0.0 Release : 1.el7.6 Host status in ACS? 1st server: Unsecure 2nd server: Disconnected Did you try to force a VM to start/deploy in this server where you

Re: Disaster after maintenance

2019-03-19 Thread Rafael Weingärtner
Can you try migrating a VM to the server that you changed the RAM amount? Also: What is the hypervisor version? Host status in ACS? Did you try to force a VM to start/deploy in this server where you changed the RAM? On Tue, Mar 19, 2019 at 9:39 AM Jevgeni Zolotarjov wrote: > We have Cloudstack

Disaster after maintenance

2019-03-19 Thread Jevgeni Zolotarjov
We have Cloudstack 4.11.2 setup running fine for few months (>4) The setup is very simple: 2 hosts We decided to do a maintenance to increase RAM on both servers For this we put first server to maintenance. All VMS moved to second host after a while. Then first server was shutdown, RAM increased,

Re: Best use of server NICs.

2019-03-19 Thread Jon Marshall
Hi Dag Many thanks for that, option 1 it is then 🙂 Jon From: Dag Sonstebo Sent: 19 March 2019 09:29 To: users@cloudstack.apache.org Subject: Re: Best use of server NICs. Hi Jon, In short "it depends...". Going by your hardware spec (only 1GBps NICs) I will a

Re: Best use of server NICs.

2019-03-19 Thread Dag Sonstebo
Hi Jon, In short "it depends...". Going by your hardware spec (only 1GBps NICs) I will assume (please correct me if wrong) that this is a smaller environment / lab / proof of concept? If so you won't see much of a benefit from option 2 since you simply won't have that much secondary storage tra

Re: [ANNOUNCE] New Committer: Sven Vogel

2019-03-19 Thread Sven Vogel
Hi Guys, Thank you all. I'll work hard to keep cloudstack moving forward…. Nice to meet you all on Shapeblue Usergroup Meeting in London. Thanks to Ticketmaster and Guiles! We see us on the next in London. Lets go further with cloudstack. Greetings Sven __ Sven Vogel Teamlead Platform EWE

Re: [Review] CloudMonkey v6.0.0 release announcement review request

2019-03-19 Thread Rohit Yadav
Hi Sally, Thanks for reviews, please proceed with the changes you've advised. While I've requested people already for their quotes, we don't have any so far. I've reached out to PMCs again today, so please include any quotes if they do arrive on this thread (on marketing@ ML). I think let's

Re: [VOTE] Apache CloudStack 4.12.0.0 [RC5]

2019-03-19 Thread Rohit Yadav
+1 (binding) Based on testing of usage server, recent blocker fixes. Setup/install on centos7, with advanced zone and kvm and the automated smoketests results. However, I do see some smoketests failing intermittently on master/4.12 but not on 4.11. TravisCI based CI/testing needs checking/fix