On Tue, Feb 21, 2012 at 11:23 AM, Aaron Coburn <acob...@amherst.edu> wrote:
> Hi, Andy,
> see my comments below.
> On Feb 21, 2012, at 10:28 AM, Andy Kurth wrote:
>> Hi Aaron C,
>> I took a pretty close look at vCenter.pm and tried it out on a vCenter
>> test server.  Looks good.
>> Question:  Where is the $DATACENTER variable declared and set?  I see
>> that it should contain the vCenter datacenter name you want to use but
>> don't see where it is defined.  It would be nice for the code to be
>> able to handle multiple datacenter names on the same vCenter host.
>> I'm guessing that's what $DATACENTER is used for.  The datacenter name
>> could be added to the vmprofile table.  We ~should~ theoretically be
>> able to define multiple vmhost entries which point to the same
>> computer but use different profiles.  I have come across this issue
>> related to other non-vCenter issues.  It can be useful to assign some
>> VMs to a host but configure them to use a special datastore.  You can
>> create multiple vmhost table entries pointing to the same computer and
>> configure the vmhost entries to use different profiles.  The backend
>> can handle this but the frontend gets tripped up and doesn't see the
>> VMs which are assigned to the host to be available
> I put this value in /etc/vcl/vcld.conf and updated the Utils.pm module to 
> load the value when the configuration is read.
> My logic behind this was simply to avoid modifying the database structure for 
> a custom module, but setting that value in the vmprofile would be preferred 
> now that this will be part of the general release.

It's no problem to add vmprofile.datacenter to vcl.sql and the
appropriate entries to Datastructure.pm.

I'm wondering how VMware clusters, pools, vApps, etc may fit in later
on.  Has anyone worked with these?  Do you see them fitting in the
database some day?

>> The changes you had to make to get things to work with vCenter also
>> seem to work with standalone hosts.  I incorporated the differences
>> between vCenter.pm and vSphere_SDK.pm into vSpherer_SDK.pm in my test
>> environment by doing the following:
>> -Get rid of all calls to VIExt::get_host_view and replace them with
>> $self->get_datacenter_view.  The objects returned by these seem like
>> they can be used interchangeably.
>> -Add a "begin_entity => $self->_get_datacenter_view()" to all
>> Vim::find_entity_view(s) calls.
>> -Add a "datacenter => $self->_get_datacenter_view()" argument to a few
>> calls such as the $file_manager->* calls
>> -Replace all hard-coded references to the default standalone
>> datacenter name "ha-datacenter" to $datacenter->{name}
>> -Make a minor change to _get_datastore_info where it checks if the
>> datastore URL begins with /vmfs/volumes.  Add checks for the
>> additional paths which may be returned when connecting to vCenter such
>> as netfs: and sanfs:.
> If the code works for standalone hosts and can all be put into the 
> vSphere_SDK module, then it would make a lot of sense to just have one 
> module. It also would simplify the issue you mention below regarding the 
> VMware::initialize subroutine.

>> I encountered the problem you mentioned in the Jira issue regarding
>> vCenter not being able to copy a virtual disk using CopyVirtualDisk.
>> That stinks...  I like your workaround.
> Just to clarify -- I have employed two different work-arounds for this. The 
> first one used a FileManager object to explicitly copy each disk extent. That 
> worked... except that it didn't preserve the thin-provisionedness of the 
> virtual disks, which was highly problematic for our datastore. The better 
> approach (for many reasons) is to use the CloneVM method. The only "gotcha" 
> here is that VMware may silently truncate the names and enclosing directories 
> of the virtual disks during a Clone operation. You had mentioned earlier that 
> the VMware::get_vmdk_file_path subroutine could handle this with minor 
> modifications.

Yes, was referring to the clone method.  I haven't tried it out yet
but will look at updating get_vmdk_file_path once I do.

>> How would you like to proceed?  I can commit the changes to
>> vSphere_SDK.pm and I don't think it will adversely affect standalone
>> hosts currently using the module nor should it affect what you're
>> currently using since the changes made are to subroutines overridden
>> in vCenter.pm.  We can also add vCenter.pm and add code to
>> VMware.pm::initialize to try to load it as discussed in the 2.3
>> release thread.  Duplicated code can be removed from vCenter.pm after
>> you have a chance to test it.
> If it is possible to have a single module to handle both stand-alone and 
> clustered hosts, then I believe that would be a much better design.

OK, I'll work on committing vSphere_SDK.pm.

> One other issue that I had when moving from a single ESX host to the vCenter 
> is that the VIExt::http_(put|get)_file subroutines became intermittently less 
> reliable. By intermittently, I mean that it failed about once for every fifty 
> attempts. After having no luck trying to diagnose the problem, I simply 
> defined an additional (optional) parameter in the copy_file_from and 
> copy_file_to subroutines. That parameter ($attempts) allowed me to 
> recursively call the copy_file_from/to routine if an attempt failed. This is 
> what the code looks like in the copy_file_to subroutine:
> sub copy_file_to {
>    ...
>    my ($from, $to, $attempts) = @_;
>    $attempts = 0 unless $attempts;
>    ...
>    if ($response->is_success) {
>        notify($ERRORS{'DEBUG'}, 0, "copied file from management node to VM 
> host: '$source_file_path' --> $vmhost_hostname:'[$destination_datastore_name] 
> $destination_relative_datastore_path'");
>        return 1;
>    }
>    else {
>        notify($ERRORS{'WARNING'}, 0, "failed to copy file from management 
> node to VM host: '$source_file_path' --> 
> $vmhost_hostname:'$destination_file_path'\nerror: " . $response->message);
>        if ($attempts > 3){
>            return;
>        } else {
>            notify($ERRORS{'DEBUG'}, 0, "trying again");
>            sleep 5;
>            return $self->copy_file_to($from, $to, ++$attempts);
>        }
>    }
> }
> A similar block exists in the copy_file_from subroutine. As you can see I set 
> the $attempts value at only 3 and have had no problems in five months. When I 
> inspect the logs, though, I still find that the GET/PUT requests fail 
> intermittently, so I have left this code in place.

Same issue here but it was more like 1 in 5 attempts.  vSphere would
throw a timeout fault I believe.  For loops like this, you can use
Module.pm::code_loop_timeout.  I wrote it after getting tired of
writing similar loops in several places.

> Finally, one more issue I encountered was that the VMware module will call 
> vmhost_os->create_directory($destination_directory_path) in the copy_vmdk 
> subroutine. This causes problems for the CloneVM method, as it does not clone 
> a virtual disk into an existing directory on a datastore. So I just wrapped 
> that in a conditional:
> if( ref($self->{api}) ne "VCL::Module::Provisioning::VMware::vCenter"){
>        ...
> }

The create_directory call can be removed VMware.pm::copy_vmdk and put
into the copy_virtual_disk subroutines where appropriate.  I
originally put it in copy_vmdk because all of the API/SDK copy methods
seem to fail if the parent directory doesn't already exist.

> So yes, if you add these to the vSphere_SDK module, I will happily test it!
> Aaron


Reply via email to