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
