Re: bump: Re: weird host profile behavior

[William Robinson]

thanks, Aaron.  i will change the management node info and re-check. will On 09/17/2012 11:18 AM, Aaron Coburn wrote: Will, Related to your questions: 1) Any Windows OS activations are removed prior to capture. Windows images are re-activated when they are loaded in the VCL, using either the MAK or KMS configuration you have set up. 2) The VMs remain in the 'reload' state because of an error. I am not entirely sure what the error is, but judging from the attached log, the issue appears to be with the management node configuration. I would try two things -- first, I wouldn't use 'localhost' as the management node hostname. I am not sure why that would cause an error, but I would use a FQDN.  Next, I would suggest looking into the warning about zero rows returned from the database when trying to determine the predictive reload module. For instance, if you run this SQL query on the vcl database, do you see values in all fields? SELECT mn.id, mn.hostname, s.name AS state, pm.name AS predictive_module FROM managementnode AS mn LEFT JOIN state AS s   ON s.id=mn.stateid LEFT JOIN module AS pm   ON pm.id=mn.predictivemoduleid If not, go to the management node configuration page and make sure the values are set properly. Hope that helps, Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College acob...@amherst.edu On Sep 17, 2012, at 10:23 AM, William Robinson <w...@exchange.clemson.edu> wrote: can anyone offer some insight on this?  i believe it is preventing us from creating new reservations.  thanks. will On 09/12/2012 01:23 PM, William Robinson wrote: just an update on this: in re-initializing the image, i seemed to be able to access the image more than once now (i added a MAK key, which solved one issue).  however, at the end of the reservation, i'm getting the email message included below and another that says activation was unsuccessful, even though it reports success when i log into the vm.  This leads me to a couple of questions:      1) the OS was activated prior to the image being captured. is this information ignored?      2) is the management node information relevant to why loaded vms remain in the "reload" state?  did i miss a setting for this? thanks. From: "r...@vcl.palmetto.clemson.edu" <r...@vcl.palmetto.clemson.edu> To: "r...@vcl.palmetto.clemson.edu" <r...@vcl.palmetto.clemson.edu> Date: Wed, 12 Sep 2012 09:29:27 -0400 Subject: PROBLEM --   localhost|4:4|timeout|DataStructure.pm|vclvm0001-man0>vclhv01|vmwarewin7-win7_x86_base2-v0|admin unable to obtain management node info for this node, returning current reservation image information ------------------------------------------------------------------------ time: 2012-09-12 09:29:27 caller: DataStructure.pm:get_next_image_dataStructure(1220) ( 0) DataStructure.pm, get_next_image_dataStructure (line: 1220) (-1) reclaim.pm, insert_reload_and_exit (line: 198) (-2) reclaim.pm, process (line: 159) (-3) vcld, make_new_child (line: 571) (-4) vcld, main (line: 350) ------------------------------------------------------------------------ management node: localhost reservation PID: 26409 parent vcld PID: 28522 request ID: 4 reservation ID: 4 request state/laststate: timeout/inuse request start time: 2012-09-12 08:45:00 request end time: 2012-09-12 10:00:00 for imaging: no log ID: 2 computer: vclvm0001-man0 computer id: 5 computer type: virtualmachine computer eth0 MAC address: 00:50:56:00:00:01 computer eth1 MAC address: 00:50:56:00:00:02 computer private IP address: 10.128.64.100 computer public IP address: 10.128.64.200 computer in block allocation: no provisioning module: VCL::Module::Provisioning::VMware::VMware vm host: vclhv01 vm host ID: 1 vm host computer ID: 1 vm profile: VMware ESXi - double disk vm profile VM path: /vmfs/volumes/datastore2 vm profile repository path: /images/vcl_repo vm profile datastore path: /vmfs/volumes/datastore2 vm profile disk type: dedicated image: vmwarewin7-win7_x86_base2-v0 image display name: win7_x86_base image ID: 2 image revision ID: 2 image size: 15168 MB use Sysprep: no root access: yes image owner ID: 1 image owner affiliation: Local image revision date created: 2012-09-11 13:14:02 image revision production: yes OS module: VCL::Module::OS::Windows::Version_6::7 user: admin user name: vcl admin user ID: 1 user affiliation: Local ------------------------------------------------------------------------ RECENT LOG ENTRIES FOR THIS PROCESS: |26409|4:4|timeout| classId = ""> |26409|4:4|timeout| bus = 14, |26409|4:4|timeout| slot = 13, |26409|4:4|timeout| function = 0, |26409|4:4|timeout| vendorId = 4098, |26409|4:4|timeout| subVendorId = 4136, |26409|4:4|timeout| vendorName = "ATI Technologies Inc", |26409|4:4|timeout| deviceId = 20830, |26409|4:4|timeout| subDeviceId = 435, |26409|4:4|timeout| parentBridge = "00:1e.0", |26409|4:4|timeout| deviceName = "ES1000", |26409|4:4|timeout| } |26409|4:4|timeout| ], |26409|4:4|timeout| cpuFeature = (vim.host.CpuIdInfo) [ |26409|4:4|timeout| (vim.host.CpuIdInfo) { |26409|4:4|timeout| dynamicType = <unset>, |26409|4:4|timeout| level = 0, |26409|4:4|timeout| vendor = <unset>, |26409|4:4|timeout| eax = "0000:0000:0000:0000:0000:0000:0000:1010", |26409|4:4|timeout| ebx = "0111:0101:0110:1110:0110:0101:0100:0111", |26409|4:4|timeout| ecx = "0110:1100:0110:0101:0111:0100:0110:1110", |26409|4:4|timeout| edx = "0100:1001:0110:0101:0110:1110:0110:1001", |26409|4:4|timeout| }, |26409|4:4|timeout| (vim.host.CpuIdInfo) { |26409|4:4|timeout| dynamicType = <unset>, |26409|4:4|timeout| level = 1, |26409|4:4|timeout| vendor = <unset>, |26409|4:4|timeout| eax = "0000:0000:0000:0001:0000:0110:0111:0110", |26409|4:4|timeout| ebx = "0000:0000:0000:0100:0000:1000:0000:0000", |26409|4:4|timeout| ecx = "0000:0000:0000:1100:1110:0011:1011:1101", |26409|4:4|timeout| edx = "1011:1111:1110:1011:1111:1011:1111:1111", |26409|4:4|timeout| }, |26409|4:4|timeout| (vim.host.CpuIdInfo) { |26409|4:4|timeout| dynamicType = <unset>, |26409|4:4|timeout| level = -2147483648, |26409|4:4|timeout| vendor = <unset>, |26409|4:4|timeout| eax = "1000:0000:0000:0000:0000:0000:0000:1000", |26409|4:4|timeout| ebx = "0000:0000:0000:0000:0000:0000:0000:0000", |26409|4:4|timeout| ecx = "0000:0000:0000:0000:0000:0000:0000:0000", |26409|4:4|timeout| edx = "0000:0000:0000:0000:0000:0000:0000:0000", |26409|4:4|timeout| }, |26409|4:4|timeout| (vim.host.CpuIdInfo) { |26409|4:4|timeout| dynamicType = <unset>, |26409|4:4|timeout| level = -2147483647, |26409|4:4|timeout| vendor = <unset>, |26409|4:4|timeout| eax = "0000:0000:0000:0000:0000:0000:0000:0000", |26409|4:4|timeout| ebx = "0000:0000:0000:0000:0000:0000:0000:0000", |26409|4:4|timeout| ecx = "0000:0000:0000:0000:0000:0000:0000:0001", |26409|4:4|timeout| edx = "0010:0000:0001:0000:0000:1000:0000:0000", |26409|4:4|timeout| }, |26409|4:4|timeout| (vim.host.CpuIdInfo) { |26409|4:4|timeout| dynamicType = <unset>, |26409|4:4|timeout| level = -2147483640, |26409|4:4|timeout| vendor = <unset>, |26409|4:4|timeout| eax = "0000:0000:0000:0000:0011:0000:0010:0110", |26409|4:4|timeout| ebx = "0000:0000:0000:0000:0000:0000:0000:0000", |26409|4:4|timeout| ecx = "0000:0000:0000:0000:0000:0000:0000:0000", |26409|4:4|timeout| edx = "0000:0000:0000:0000:0000:0000:0000:0000", |26409|4:4|timeout| } |26409|4:4|timeout| ], |26409|4:4|timeout| biosInfo = (vim.host.BIOSInfo) { |26409|4:4|timeout| dynamicType = <unset>, |26409|4:4|timeout| biosVersion = "2.5.0", |26409|4:4|timeout| releaseDate = "2008-09-12T00:00:00Z", |26409|4:4|timeout| }, |26409|4:4|timeout| } 2012-09-12 09:29:27|26409|4:4|timeout|utils.pm:run_ssh_command(5068)|SSH command executed on vclhv01, returning (0, "(vim.host.HardwareInfo) { dyna...") 2012-09-12 09:29:27|26409|4:4|timeout|VIM_SSH.pm:_run_vim_cmd(208)|executed command on VM host vclhv01: vim-cmd hostsvc/hosthardware 2012-09-12 09:29:27|26409|4:4|timeout|VIM_SSH.pm:get_total_memory(1988)|retrieved VM host vclhv01 total memory capacity: 12282 MB 2012-09-12 09:29:27|26409|4:4|timeout|utils.pm:update_computer_ram(1749)|updated the RAM value to 12282 for computer ID 1 2012-09-12 09:29:27|26409|4:4|timeout|utils.pm:update_computer_lastcheck(1631)|computer 1 lastcheck updated to: 2012-09-12 09:29:27 2012-09-12 09:29:27|26409|4:4|timeout|Module.pm:create_provisioning_object(525)|VCL::Module::Provisioning::VMware::VMware provisioner object created for vclvm0001-man0, address: 2af14c0 2012-09-12 09:29:27|26409|4:4|timeout|State.pm:initialize(154)|returning 1 2012-09-12 09:29:27|26409|4:4|timeout|vcld:make_new_child(568)|VCL::reclaim object created and initialized 2012-09-12 09:29:27|26409|4:4|timeout|DataStructure.pm:get_computer_state_name(2433)|attempting to retrieve current state of computer vclvm0001-man0 from the database 2012-09-12 09:29:27|26409|4:4|timeout|DataStructure.pm:get_computer_state_name(2464)|retrieved current state of computer vclvm0001-man0 from the database: timeout 2012-09-12 09:29:27|26409|4:4|timeout|DataStructure.pm:_automethod(836)|data structure updated, hash path: $self->request_data->{reservation}{4}{computer}{state}{name}, data identifier: computer_state_name, data: |26409|4:4|timeout| : "timeout" 2012-09-12 09:29:27|26409|4:4|timeout|utils.pm:insertloadlog(3703)|inserted computer=5, timeout, reclaim: starting timeout process 2012-09-12 09:29:27|26409|4:4|timeout|reclaim.pm:process(107)|beginning to reclaim vclvm0001-man0: |26409|4:4|timeout| request state: timeout |26409|4:4|timeout| request laststate: inuse |26409|4:4|timeout| computer state: timeout |26409|4:4|timeout| computer type: virtualmachine 2012-09-12 09:29:27|26409|4:4|timeout|reclaim.pm:process(158)|request laststate is inuse, computer will be reloaded |26409|4:4|timeout| ---- WARNING ---- |26409|4:4|timeout| 2012-09-12 09:29:27|26409|4:4|timeout|utils.pm:get_management_predictive_info(5441)|zero rows were returned from database select |26409|4:4|timeout| ( 0) utils.pm, get_management_predictive_info (line: 5441) |26409|4:4|timeout| (-1) DataStructure.pm, get_next_image_dataStructure (line: 1218) |26409|4:4|timeout| (-2) reclaim.pm, insert_reload_and_exit (line: 198) |26409|4:4|timeout| (-3) reclaim.pm, process (line: 159) |26409|4:4|timeout| (-4) vcld, make_new_child (line: 571) |26409|4:4|timeout| (-5) vcld, main (line: 350) 2012-09-12 09:29:27|26409|4:4|timeout|DataStructure.pm:get_computer_private_ip_address(1630)|attempting to retrieve private IP address for computer: vclvm0001-man0 2012-09-12 09:29:27|26409|4:4|timeout|DataStructure.pm:get_computer_private_ip_address(1634)|retrieved contents of /etc/hosts on this management node, contains 129 lines 2012-09-12 09:29:27|26409|4:4|timeout|DataStructure.pm:get_computer_private_ip_address(1694)|returning IP address from /etc/hosts file: 10.128.64.100 2012-09-12 09:29:27|26409|4:4|timeout|utils.pm:is_inblockrequest(5798)|zero rows were returned from database select 2012-09-12 09:29:27|26409|4:4|timeout|DataStructure.pm:get_image_affiliation_name(2118)|image owner id: 1 2012-09-12 09:29:27|26409|4:4|timeout|DataStructure.pm:retrieve_user_data(1401)|attempting to retrieve and store data for user: user.id = '1' 2012-09-12 09:29:27|26409|4:4|timeout|DataStructure.pm:retrieve_user_data(1464)|data has been retrieved for user: admin (id: 1) will On 09/10/2012 08:54 AM, William Robinson wrote: hi all, i'm noticing some weird behavior with my vm hosts profiles where the "repository image type" and the "virtual disk image type" always revert back to "kickstart" (I had them set to "vmdk").  i noticed this when trying to diagnose why VMs would be stuck in the "reload" state after reservation completion (i was not able to complete subsequent reservations).  has anyone seen this type of behavior before?  thanks.