Re: SystemVM documentation

Great... thank you Marc-Aurele and Rohit! On 2/16/18, 8:39 PM, "Rohit Yadav" wrote: Raja, as Marc-Aurele has shared refer to the README in tools/appliance; the build process has been greatly simplified and only requires packer on a KVM box with bunch of

SystemVM documentation

Hi Rohit, Can you please point to the documentation you may have for creating the 4.11 SystemVMs ? Best, Raja 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

RE: HA issues

We've done a lot of work on VM HA (we are on 4.9.3) and have it working reliably. We've also been able stop the problem of VMs getting started on two hosts during some HA events. Since this is 4.9.3, we do not use IPMI for this functionality. We have not testing how the addition of IPMI in

Potential backward incompatibility problem in building SystemVM

Hi I just noticed that the changes [1] in tools/applince/build.sh may break backward compatibility of the building process of systemvmtremplate. In the highlighted (and now removed) line, we used to have a predefined name as "systemvm64template" and if one still wants to execute "build.sh

Re: SystemVM documentation

Raja, as Marc-Aurele has shared refer to the README in tools/appliance; the build process has been greatly simplified and only requires packer on a KVM box with bunch of utilities for exporting appliances in various formats. - Rohit

Re: SystemVM documentation

There's a readme in the directory for the systemVM: https://github.com/apache/cloudstack/tree/master/tools/appliance On Fri, Feb 16, 2018 at 2:11 PM, Raja Pullela wrote: > Hi Rohit, > > Can you please point to the documentation you may have for creating the > 4.11

Re: HA issues

>From your other emails it sounds as though you do not have IPMI configured, nor host HA enabled, correct? In this case, the correct thing to do is nothing. If CloudStack cannot guarantee the VM state (as is the case with an unreachable hypervisor), it should do nothing, for fear of causing a

RE: HA issues

We were in the same situation as Nux. In our test environment we hit the issue with VMs not getting fenced and coming up on two hosts because of VM HA. However, we updated some of the logic for VM HA and turned on libvirtd's locking mechanism. Now we are working great w/o IPMI. The locking