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 <[email protected]> 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 >>> >>> >
