[GitHub] [cloudstack-documentation] nvazquez opened a new pull request #70: Add support for Vmware 6.7

[GitBox]

nvazquez opened a new pull request #70: Add support for Vmware 6.7
URL: https://github.com/apache/cloudstack-documentation/pull/70
 
 
   Include Vmware 6.7 to the compatibility matrix
   
   Source: https://github.com/apache/cloudstack/pull/3413


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [cloudstack-documentation] PaulAngus commented on a change in pull request #70: Add support for Vmware 6.7

[GitBox]

PaulAngus commented on a change in pull request #70: Add support for Vmware 6.7
URL: 
https://github.com/apache/cloudstack-documentation/pull/70#discussion_r320762638
 
 

 ##
 File path: source/releasenotes/compat.rst
 ##
 @@ -48,7 +48,7 @@ and VMware with vSphere.
 
.. note:: It is now required to enable HA on the XenServer pool in order to 
recover from a pool-master failure. Please refer to the `XenServer 
documentation `_.
 
--  VMware versions 5.0 Update 3, 5.1 Update 3, 5.5 Update 3b, 6.0 Update 2, 
and 6.5 GA
+-  VMware versions 5.0 Update 3, 5.1 Update 3, 5.5 Update 3b, 6.0 Update 2, 
6.5 GA and 6.7
 
 Review comment:
   ```suggestion
   -  VMware versions 5.0, 5.1, 5.5, 6.0, 6.5 and 6.7
  .. note:: There is a known issue in 6.7u1 
(https://kb.vmware.com/s/article/67315) which blocks some 
 CloudStack cloning operations. The use of linked clones is known to be 
effected.
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

SolidFire CloudStack 4.11.3 and VMWare 6.5

[Tutkowski, Mike]

Can you take a look in the cloud.host table and see if the IQN of each of the 
relevant hosts is populated in the url cell?

If it is not, you might have to run the force reconnect command on each 
applicable host (this is a CloudStack command).

From: christian.nieph...@zv.fraunhofer.de 
Sent: Wednesday, September 4, 2019 9:19 AM
To: us...@cloudstack.apache.org
Cc: christian.kir...@zv.fraunhofer.de
Subject: SolidFire CloudStack 4.11.3 and VMWare 6.5

Hi,
we are currently doing a PoC with SolidFire and CloudStack and trying to figure 
out if it’s a fitting solution for our use cases.

But I am stuck at the point when CloudStack tries to create a VM on the solid 
fire storage.
I can see that it has already copied the template to a SolidFire Volume but 
then the error message "Not all hosts in the compute cluster support iSCSI.” 
appears in the logs.

On the ESXi I have created a iSCSI HBA and attached it to a VMKernel adapter, 
is there anything else to do?
Is there any documentation for the setup? I have only found the youtube videos 
by Mike, but they does not focus on the vsphere setup part.


Regards Christian

Re: SolidFire CloudStack 4.11.3 and VMWare 6.5

[Andrija Panic]

Hi Christian,

there is an old page here:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Configuration+Guide

It seems that you would create iSCSI HBA  and add datastore via vCenter,
later you add Primary Storage to ASC, by choosing "vmfs" as the protocol.

Check the thing that Mike mentioned, and double-check if you did not skip
some host for iSCSI HBA configuration.

Andrija

On Wed, 4 Sep 2019 at 20:08, Tutkowski, Mike 
wrote:

> Can you take a look in the cloud.host table and see if the IQN of each of
> the relevant hosts is populated in the url cell?
>
> If it is not, you might have to run the force reconnect command on each
> applicable host (this is a CloudStack command).
> 
> From: christian.nieph...@zv.fraunhofer.de <
> christian.nieph...@zv.fraunhofer.de>
> Sent: Wednesday, September 4, 2019 9:19 AM
> To: us...@cloudstack.apache.org
> Cc: christian.kir...@zv.fraunhofer.de
> Subject: SolidFire CloudStack 4.11.3 and VMWare 6.5
>
> Hi,
> we are currently doing a PoC with SolidFire and CloudStack and trying to
> figure out if it’s a fitting solution for our use cases.
>
> But I am stuck at the point when CloudStack tries to create a VM on the
> solid fire storage.
> I can see that it has already copied the template to a SolidFire Volume
> but then the error message "Not all hosts in the compute cluster support
> iSCSI.” appears in the logs.
>
> On the ESXi I have created a iSCSI HBA and attached it to a VMKernel
> adapter, is there anything else to do?
> Is there any documentation for the setup? I have only found the youtube
> videos by Mike, but they does not focus on the vsphere setup part.
>
>
> Regards Christian
>


-- 

Andrija Panić

Re: kvm: /var/log/cloudstack/agent/agent.log is a binary file

[Wido den Hollander]

On 9/3/19 2:55 PM, Daan Hoogland wrote:
> On Tue, Sep 3, 2019 at 2:22 PM Wido den Hollander  wrote:
> 
>>
>>
>> On 9/3/19 9:57 AM, Daan Hoogland wrote:
>>> Can you find/look at the line before in the log. It is probably the one
>>> containing the hindering data. Or otherwise it *might* be a clue where in
>>> the flow it happens.
>>>
>>
>> Do you have any idea what the easiest way might be?
>>
> In short, no, but.. in totally skewed order of alleged quickness
> 1: I'm afraid it is a line by line analysis. If you are lucky the line
> start with date and class name is not obscured and there is a newline
> entered in the log. That would give you the exact location. when in bad
> luck the binary data contains control chars that erase to beginning of line
> or so and the best you can find is the previous and next lines.
> 3: code analysis; My first thought is that some binary data is read from a
> file or a socket and logged as is. but starting this with code analysis is
> not the quickest way to get to the culprit I imagine.
> 2: Other than line by line log analysis and if you can reproduce the issue,
> you could try zooming in by playing around with log levels for different
> classes.
> 

I checked, but on all hypervisors I checked the "agent.log" contains
binary data, but all the rotated (.gz) files do not.

The binary data is at the beginning of the file(s). So it seems like it
is logrotate and maybe a combination of log4j causing this?

I'm not sure yet, but that seems to be the case.

Wido

> 
>>
>> I checked agent.log.1.gz and after I decompress is that file is not
>> binary, text only.
>>
> so much for reproducibilty. Hope it was not a buffer overflow hack attempt.
> 
> 
>>
>> The binary data only seems to be present in the current file.
>>
>> Wido
>>
>>> On Tue, Sep 3, 2019 at 8:22 AM Wido den Hollander 
>> wrote:
>>>


 On 9/2/19 10:18 PM, Wei ZHOU wrote:
> Hi Wido,
>
> I had similar issue (not agent.log). It is probably caused by one or
 few> lines with special characters.

 And I'm trying to figure out what causes it :-)

> "grep -a" should work.

 I know, but other tools which analyze the logfile might also have
 trouble reading the file due to binary characters.

 Wido

>
> -Wei
>
> On Mon, 2 Sep 2019 at 19:35, Wido den Hollander 
>> wrote:
>
>> Hi,
>>
>> I've seen this on multiple occasions with Ubuntu 18.04 (and maybe
>> 16.04?) hypervisors where according to 'grep' the agent.log is a
>> binary
>> file:
>>
>> root@n06:~# grep security_group /var/log/cloudstack/agent/agent.log
>> Binary file /var/log/cloudstack/agent/agent.log matches
>> root@n06:~#
>>
>> If I open the file with 'less' I indeed see binary data.
>>
>> Tailing the file works just fine.
>>
>> Does anybody know where this is coming from? What in the CloudStack
>> agent causes it to write binary data to the logfile?
>>
>> Wido
>>
>



>>>
>>
> 
>