Network label of a portgroup is kept in UNICODE internally.

[luger_lee]

Hi, everybody

==============

1 my $host = Vim::find_entity_view(view_type => 'HostSystem', filter => {name => $hostname}, properties => ['name', 'network']);

2 print Dumper $host->network;

3 my $network = Vim::get_views(mo_ref_array => $host->network, properties => ['name', 'host', 'vm']);

4 foreach (@$network) {

5     print Dumper $_;

6 }

==============

i ran above code, but i got the error below at lint 3.

==============

Content-Length header value was wrong, fixed at C:/VMware/vSphereCLI5.0/Perl/lib/LWP/Protocol/http.pm line 189.

SOAP Fault:

-----------

Fault string:

Error returned by expat parser: unclosed token

while parsing SOAP body

at line 5, column 3

while parsing SOAP envelope

at line 2, column 3

while parsing HTTP request for method retrieveContents

on object of type vmodl.query.PropertyCollector

at line 1, column 0

Fault detail: InvalidRequestFault

==============

line 2 output details of the networks shown below. yes, the name of network is in UNICODE rather than UTF-8.

==============

$VAR1 = [

          bless( {

                   'value' => 'HaNetwork-VM Network',

                   'type' => 'Network'

                 }, 'ManagedObjectReference' ),

          bless( {

                   'value' => "HaNetwork-\x{4eee}\x{60f3}\x{30de}\x{30b7}\x{30f3} \x{30cd}\x{30c3}\x{30c8}\x{30ef}\x{30fc}\x{30af}",

                   'type' => 'Network'

                 }, 'ManagedObjectReference' )

        ];

==============

any hint is appreciated. thanks in advance.

[luger_lee]

A service request has been sent to VMware.

=================================================================

Dear Sir/Madam

I wrote a Perl script to obtain a list of names for Virtual Machine Port Group (also known as Network Labels) from my VMware ESXi server (version 5.1.0, build 799733) as follows:

use strict;

use VMware::VIRuntime;

Opts::parse();

Opts::validate();

Util::connect();

my $host_view = Vim::find_entity_view(view_type => 'HostSystem', filter => {name => 'my_esxi510'}, properties => ['name', 'network']);

$Data::Dumper::Indent = 1;

my $host_networks_ref = $host_view->network;

foreach (@$host_networks_ref) {

my $network_view = Vim::get_view(mo_ref => $_, properties => ['name', 'host', 'vm']);

print Dumper $network_view;

}

Util::disconnect();

I have encountered the following error when running the script above:

>sample.pl

Content-Length header value was wrong, fixed at C:/VMware/vSphereCLI5.5.0/Perl/lib/LWP/Protocol/http.pm line 189.

SOAP Fault:

-----------

Fault string:

Error returned by expat parser: unclosed token

while parsing SOAP body

at line 5, column 3

while parsing SOAP envelope

at line 2, column 3

while parsing HTTP request for method retrieveContents

on object of type vmodl.query.PropertyCollector

at line 1, column 0

Fault detail: InvalidRequestFault

I did some research and it seemed that LWP::Protocol::http could not correctly compare a length for the content of HTTP request with the one defined in ‘Content-Length‘ property when involving an UTF-8 character, because the length() function doesn't deals in physical bytes.

Details

1. 1. The one of the Virtual Machine Port Groups was added with multi-byte characters in the name (the network label) from the vSphere Client (version 5.1.0 build 786111).
2. 2.    I got correct Virtual Machine Port Group name list after I modified http.pm by adding the following one line to it:

use bytes;

1. 3. A Virtual Machine Port Group with multi-byte characters in the name can’t be added to a VMware ESXi server (version 4.1.0) from a vSphere Client (version 4.1.0).
2. 4. VMware vSphere Perl SDK 5.5.0 (1292267) and VMware vSphere Perl SDK 5.1.0 (780721) are used in my testing environment, both produce the same result.

Here we have some questions regarding multi-byte characters.

1. 1. How could I get a correct Virtual Machine Port Group name in multi-byte characters when using VMware vSphere Perl SDK 5.1.0 or VMware vSphere Perl SDK 5.5.0?
2. 2. May I understand this issue is flagged as known problem?
3. 3. If it’s a known issue, when it will be reflected in the VMware KB?

Any helpful hints and tips are appreciated.

Sincerely,

lee

=================================================================

[luger_lee]

And the response from VMware has been received as following:

================================================

Thank you for your patience. As per details provided in the problem description, we have logged an internal bug and escalated your request.

It is now assigned to sustaining engineering for resolution. Once we have an update from them, we will communicate the information to you.

Resolution times will vary depending on severity of issue and other factors. We will wait on this case until we receive updates from sustaining engineering.

Please let me know if you have any other concerns.

Case Reported:[NRI] Getting an error "Content-Length header value was wrong"

Status: Waiting on Engineering

================================================

[stumpr]

luger_lee,

I did a quick test, but I used the new vSphere Perl SDK 5.5 against a vSphere 5.1 environment.  I renamed a distributed virtual port group and a standard port group using the unicode string name you provided in your first post ("HaNetwork-\x{4eee}\x{60f3}\x{30de}\x{30b7}\x{30f3} \x{30cd}\x{30c3}\x{30c8}\x{30ef}\x{30fc}\x{30af}").  This is Kanji right?  I haven't done i8n work in ages, so forgive my ignorance there but the string did enter and display correctly into the vSphere client.

In any event, I ran your script (with a small modification, just Dumped the name property) and it ran successfully.  This was on Windows 2008 with the vCLI installation of the Perl SDK.  Of course, the names displayed in the console was in the unicode encoding format. 

Since you should have few issues backwards compat wise from 5.5 to 5.0/5.1, perhaps try a fresh install of vCLI 5.5.  It might have a different library version of LWP.  I confirmed my vSphere client version is the same as yours (build 786111).

However, I do notice that the SDK does use the content call of the request response, not decoded_content, which is usually better for encoded data (such as unicode).  Just can't seem to get the same error with the versions I have.