Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

[Pavan Kumar Aravapalli]

Thank you Bobby and Daan for the update. However I have not encountered such 
issue while doing dev test with Vmware 5.5 & 6.5.





Regards,

Pavan Aravapalli.



From: Daan Hoogland 
Sent: 19 May 2020 20:56
To: users 
Cc: d...@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

Thanks Bobby,
All, I've been closely working with Bobby and seen the same things. Does
anybody see any issues releasing 4.14 based on this code? I can confirm
that it is not Pavernalli's UEFI PR and we should not create a new PR to
revert it.
thanks for all of your patience,

(this is me giving a binding +1)


On Tue, May 19, 2020 at 5:04 PM Boris Stoyanov 
wrote:

> Hi guys,
>
> I've done more testing around this and I can now confirm it has nothing to
> do with cloudstack code.
>
> I've tested it with rc3, reverted UEFI PR and 4.13.1 (which does not
> happen to have the feature at all). Also I've used a matrix of VMware
> version of 6.0u2, 6.5u2 and 6.7u3.
>
> The bug is reproducible with all the cloudstack versions, and only vmware
> 6.7u3, I was not able to reproduce this with 6.5/6.0. All of my results
> during testing show it must be related to that specific version of VMware.
>
> Therefore I'm reversing my '-1' and giving a +1 vote on the RC. I think it
> needs to be included in release notes to refrain from that version for now
> until further investigation is done.
>
> Thanks,
> Bobby.
>
> On 19.05.20, 10:08, "Boris Stoyanov" 
> wrote:
>
> Indeed it is severe, but please note it's a corner case which was
> unearthed almost by accident. It falls down to using a new feature of
> selecting a boot protocol and the template must be corrupted. So with
> already existing templates I would not expect to encounter it.
>
> As for recovery, we've managed to recover vCenter and Cloudstack after
> reboots of the vCenter machine and the Cloudstack management service.
> There's no exact points to recover for now, but restart seems to work.
> By graceful failure I mean, cloudstack erroring out the deployment and
> VM finished in ERROR state, meanwhile connection and operability with
> vCenter cluster remains the same.
>
> We're currently exploring options to fix this, one could be to disable
> the feature for VMWare and work to introduce more sustainable fix in next
> release. Other is to look for more guarding code when installing a
> template, since VMware doesn’t actually allow you install that particular
> template but cloudstack does. We'll keep you posted.
>
> Thanks,
> Bobby.
>
> On 18.05.20, 23:01, "Marcus"  wrote:
>
> The issue sounds severe enough that a release note probably won't
> suffice -
> unless there's a documented way to recover we'd never want to
> leave a
> system susceptible to being unrecoverable, even if it's rarely
> triggered.
>
> What's involved in "failing gracefully"? Is this a small fix, or an
> overhaul?  Perhaps the new feature could be disabled for VMware, or
> disabled altogether until a fix is made in a patch release.
>
> Does it only affect new templates, or is there a risk that an
> existing
> template out in vSphere could suddenly cause problems?
>
> On Mon, May 18, 2020 at 12:49 AM Boris Stoyanov <
> boris.stoya...@shapeblue.com> wrote:
>
> > Hi guys,
> >
> > A little further info on this, it appears when we use a
> corrupted template
> > and UEFI/Legacy mode when deploy a VM, it breaks the connection
> between
> > cloudstack and vCenter.
> >
> > All hosts become unreachable and basically the cluster is not
> functional,
> > have not investigated a way to recover this but seems like a
> huge mess..
> > Please note that user is not able to register such template in
> vCenter
> > directly, but cloudstack allows using it.
> >
> > Open to discuss if we'll fix this, since it's expected users to
> use
> > working templates, I think we should be failing gracefully and
> such action
> > should not be able to create downtime on such a large scale.
> >
> > I believe the boot type feature is new one and it's not
> available in older
> > releases, so this issue should be limited to 4.14/current master.
> >
> > Thanks,
> > Bobby.
> >
> > On 15.05.20, 17:07, "Boris Stoyanov" <
> boris.stoya...@shapeblue.com>
> > wrote:
> >
> > I'll have to -1 RC3, we've discovered details about an issue
> which is
> > causing severe consequences with a particular hypervisor in the
> afternoon.
> > We'll need more time to investigate before disclosing.
> >
> > Bobby.
> >
> > On 15.05.20, 9:12, "Boris Stoyanov" <
> boris.stoya...@shapeblue.com>
> > wrote:
> >
> > +1 (binding)
>   

Re: Mangement server fail to detect System VMs

[Pavan Kumar Aravapalli]

Hi linxiao,

Did you observe any error log from Management Server.? Did  you observe any 
ping response messages from system vm's.  You are able to see on VM's running 
state on KVM Host but not on CP, because of  System VM's unable to reach 
Management Server with network connectivity issue.

I suggest you to login to system vm's and try performing ping management 
server(s) and check.
One thing Observed from the mail is you are using same subnet for both 
management and guest network. I have n't tried with same subnet. Any particular 
reason that you are using same same subnet??  If not try to use two different 
subnets.


Thanks
Pavan.



From: linxiao 
Sent: 11 May 2020 08:25
To: users@cloudstack.apache.org 
Subject: Mangement server fail to detect System VMs

I installed CloudStack in a two node cluster.  The management server is running 
on 11.11.11.21 and the agent is running on 11.11.11.22.  The gateway is also 
11.11.11.21.

The management server created two system vms in agent. When I type `virsh list` 
on 11.11.11.22, the statuses of secondary storage vm and console proxy vm are 
both "running".  But It seems that the management server cannot detect the 
liveliness of system vms, so the creating vm job is all timed out.

The management network ip range is between 11.11.11.53 and 11.11.11.59.
The guest network ip range is between 11.11.11.60 to 11.11.11.200.
The gateway is 11.11.11.21. The netmask is 255.255.255.0.

I think the problem is that the system vms cannot access the network 
11.11.11.0/24. Because I cannot ping or ssh VMs' public/private/link local ip 
address listed on cloudstack management server UI. But when I type `virsh 
console [VMName]`, there is a prompt for username and password.

The creating vm job log: https://paste.ubuntu.com/p/tkNHM9r8yf/
The ifconfig output of agent: https://paste.ubuntu.com/p/6BHmS995Fh/
Could anyone help me? Any help will be appreciated.
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.

Re: libvirt: Storage Driver error : Storage pool not found:

[Pavan Kumar Aravapalli]

Hi Gabriel,


The log doesn't contains any error message here. It's just information shown in 
the log on what operations performed on storage pool.


Regards,
Pavan.


From: Gabriel Velasquez 
Sent: 18 October 2019 21:58
To: users@cloudstack.apache.org 
Subject: libvirt: Storage Driver error : Storage pool not found:

I'm new to CloudStack and looking to use this in a private cloud.  
Unfortunately, I haven't been able to get the Storage and Console VM to start 
up.  I went through the install process twice and go the same result.  I 
followed the documentation step by step for the basic setup. 
http://docs.cloudstack.apache.org/en/latest/installguide/management-server/index.html

I'm only using one server.

So far it seems that the cloudstack-agent is failing.  Here's what I get in the 
logs:

 2019-10-18 09:20:08,154 INFO  [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-2:null) (logid:f9f6eee1) Asking libvirt to refresh 
storage pool 58c7233f-f02d-3442-9968-06e4481ecfdc
2019-10-18 09:21:08,265 INFO  [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-4:null) (logid:77879d49) Trying to fetch storage pool 
b79c0b0a-11a2-3d61-8451-84535600787a from libvirt
2019-10-18 09:21:08,313 INFO  [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-5:null) (logid:77879d49) Trying to fetch storage pool 
58c7233f-f02d-3442-9968-06e4481ecfdc from libvirt
2019-10-18 09:21:08,317 INFO  [kvm.storage.LibvirtStorageAdaptor] 
(agentRequest-Handler-5:null) (logid:77879d49) Asking libvirt to refresh 
storage pool 58c7233f-f02d-3442-9968-06e4481ecfdc

The Secondary Storage VM and Console Proxy VM hang in the "starting" mode

I'm using CentOS 7 and the latest CloudStack - 4.13.

Thanks for your help!
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.

Re: uefi

[Pavan Kumar Aravapalli]

Hi Piotr,

I have been working actively on this feature in branch 
https://github.com/Accelerite/cloudstack/tree/uefisupport and there is WIP PR 
https://github.com/apache/cloudstack/pull/3643.

Functional testing is in progress, Hoping to merge this feature in next few 
weeks after testing and reviews.
Please refer to functional spec  
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enable+UEFI+booting+for+Instance
 for more details.

It would be great if you help in testing our branch, and share your feedback.



Regards,
Pavan.


From: Piotr Pisz 
Sent: 09 October 2019 10:38
To: users@cloudstack.apache.org 
Subject: uefi

Hi All,

I have a question, does CloudStack with KVM support UEFI for VM?
I found this presentation: https://www.youtube.com/watch?v=r3Se_IObkrA
On which you can clearly see that you can choose UEFI, unfortunately there is 
no word about it in the CloudCtack documentation, which version are we talking 
about?

Regards,
Piotr

Reg : qemu-kvm upgrade in KVM hypervisor agent

[Pavan Kumar Aravapalli]

Hello,


As part of KVM upgrade it's found that default package 'qemu-kvm' [ which comes 
with  OS distro]  does not support machine chipset type 'q35'.  And this 
support can be leveraged by installing 'qemu-kvm-ev'  which is from 
centos-release-qemu-ev repo.


I saw some some old mail threads  saying that they have integrated qemu-kvm-ev, 
but still in agent bundle rpm requirements 
[https://github.com/apache/cloudstack/blob/master/packaging/centos7/cloud.spec] 
I found old 'qemu-kvm' only.



Can we leverage this package qemu-kvm-ev in agent rpm bundle?. Has anyone faced 
any issues in Cloud Stack after upgrading the package.



~Regards,

Pavan.

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.

Re: New VP of CloudStack: Paul Angus

[Pavan Kumar Aravapalli]

Congratulations Paul.


From: Sven Vogel 
Sent: 11 March 2019 23:12:48
To: d...@cloudstack.apache.org
Cc: users@cloudstack.apache.org
Subject: Re: New VP of CloudStack: Paul Angus

Congratulations!

Von meinem iPhone gesendet


__

Sven Vogel
Teamlead Platform

EWERK RZ GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 11
F +49 341 42649 - 18
s.vo...@ewerk.com
www.ewerk.com

Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Frank Richter, Gerhard Hoyer
Registergericht: Leipzig HRB 17023

Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 2-1:2011

EWERK-Blog | LinkedIn | Xing | Twitter | Facebook

Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.

Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist 
vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der 
bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, 
Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte 
informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die 
E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen 
Dank.

The contents of this e-mail (including any attachments) are confidential and 
may be legally privileged. If you are not the intended recipient of this 
e-mail, any disclosure, copying, distribution or use of its contents is 
strictly prohibited, and you should please notify the sender immediately and 
then delete it (including any attachments) from your system. Thank you.
> Am 11.03.2019 um 18:27 schrieb Riepl, Gregor (SWISS TXT) 
> :
>
>
>> I’m happy to announce that the CloudStack PMC has elected Paul Angus
>> as our new VP of CloudStack.
>
> Congratulations, Paul!