vcl-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Kurth <andy_ku...@ncsu.edu>
Subject Re: can't complete reservation
Date Tue, 14 Aug 2012 13:44:02 GMT
Hi Will,
Please check my reply in the "RE: New capture failed attempting
Windows post-load tasks" thread to see if this is the same issue
you're having.  If this is a different issue, please send the complete
vcld.log output for the reservation.  The following command should
filter out the reservation:
grep '|6:6|' /var/log/vcld.log

-Andy

On Tue, Aug 14, 2012 at 8:18 AM, William Robinson
<wr@exchange.clemson.edu> wrote:
> thanks for the reply.  however, i forgot to include that i'm seeing this
> behavior on a windows 7 vm.  i included much more info in the original
> email, but some server issues are preventing them from going through, so i
> whittled the log entries down as much as i could.  has this behavior been
> seen on a win7 vm?
>
> will
>
>
> On 08/13/2012 09:28 PM, Michael Jinks wrote:
>>
>> Recent Linux distributions are using rules in udev which bind interface
>> names to MAC addresses.  So when your image is redeployed to new VM
>> hardware after capture, the OS sees the new virtual network devices and
>> assigns them their own network interface names. Any configuration
>> attached to the old interface names will be lost.
>>
>> I don't know of anything within VCL itself that addresses this issue.  I
>> got around it by adjusting our Linux image prior to capture so that it
>> won't use the net device persistence rules.
>>
>> Until recently, all I ever had to do in order to disable this "feature"
>> was to delete '/etc/udev/rules.d/70-persistent-net.rules', but some
>> distributions (RHEL 6 at least) have now added a rule to bring it back
>> when udev restarts.  To make it stay gone:
>>
>>   # ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules
>>
>> I also still remove the persistent-net.rules file as well, but I don't
>> know if that's till necessary.
>>
>>
>> On Mon, Aug 13, 2012 at 04:44:39PM -0400, William Robinson wrote:
>>>
>>> (one or more duplicates of this message may come to the list due to local
>>> email
>>> issues.  if so please disregard.)
>>>
>>> hi all,
>>>
>>> in still trying to debug this, i've noticed that my image capture appears
>>> to be
>>> successful, but the vm state is 'failed'.  i've scoured through vcld.log
>>> in an
>>> effort to locate the reason.  as a novice, nothing glaring sticks out to
>>> me.  i
>>> can access the vm after the capture through websphere.  in accessing the
>>> vm, i
>>> noticed that the interfaces don't seem to get configured and the
>>> interface
>>> device names don't match what was originally configured during os
>>> install.  is
>>> there a setting i missed in vcl?  i would appreciate any hints.  thanks.
>>>
>>> relevant log entries:
>>>
>>>
>>> |6139|6:6|reload| ---- CRITICAL ----
>>> |6139|6:6|reload| 2012-08-13
>>> 13:40:01|6139|6:6|reload|State.pm:reservation_failed(240)|reservation
>>> failed on
>>> vclvm0001-man0: process failed after trying to load or make available
>>> |6139|6:6|reload| ( 0) State.pm, reservation_failed (line: 240)
>>> |6139|6:6|reload| (-1) new.pm, process (line: 341)
>>> |6139|6:6|reload| (-2) vcld, make_new_child (line: 571)
>>> |6139|6:6|reload| (-3) vcld, main (line: 350)
>>> 2012-08-13 13:40:02|6139|6:6|reload|utils.pm:insertloadlog(3703)|inserted
>>> computer=5, failed, process failed after trying to load or make available
>>> 2012-08-13
>>> 13:40:02|6139|6:6|reload|State.pm:reservation_failed(243)|inserted
>>> computerloadlog entry
>>> 2012-08-13
>>> 13:40:02|6139|6:6|reload|utils.pm:update_computer_state(1587)|computer 5
>>> state
>>> updated to: failed
>>> 2012-08-13
>>> 13:40:02|6139|6:6|reload|State.pm:reservation_failed(262)|computer
>>> vclvm0001-man0 (5) state set to failed
>>> 2012-08-13
>>> 13:40:02|6139|6:6|reload|utils.pm:update_request_state(1545)|request
>>> 6 state updated to: failed, laststate to: image
>>> 2012-08-13 13:40:02|6139|6:6|reload|State.pm:reservation_failed(275)|set
>>> request
>>> state to 'failed'/'image'
>>> 2012-08-13 13:40:02|6139|6:6|reload|utils.pm:is_inblockrequest(5793)|zero
>>> rows
>>> were returned from database select
>>> 2012-08-13
>>> 13:40:02|6139|6:6|reload|State.pm:reservation_failed(293)|vclvm0001-man0
>>> is NOT
>>> in blockcomputers table
>>> 2012-08-13
>>> 13:40:02|6139|6:6|reload|State.pm:reservation_failed(296)|exiting 1
>>> 2012-08-13
>>>
>>> 13:40:02|6139|6:6|reload|utils.pm:delete_computerloadlog_reservation(6429)|removing
>>> computerloadlog entries matching loadstate = begin
>>> 2012-08-13
>>>
>>> 13:40:02|6139|6:6|reload|utils.pm:delete_computerloadlog_reservation(6476)|deleted
>>> rows from computerloadlog for reservation id=6
>>> 2012-08-13 13:40:02|6139|6:6|reload|State.pm:DESTROY(929)|VCL::new
>>> process
>>> duration: 647 seconds
>>> 2012-08-13 13:40:02|6139|6:6|reload|VIM_SSH.pm:DESTROY(2123)|vim-cmd call
>>> count: 16
>>>
>>> will
>>>
>>>
>

Mime
View raw message