[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Trying to get CentOS guest running, but xm cant find the kernel image.



Thanks, that got me further.  Now I think I may be running into a
problem with the initrd file.  Should I have generated a special one
when I generated the kernel?

I'm crashing the guest:

>From xend-debug.log
Nothing to flush.
Traceback (most recent call last):
  File "/usr/lib/python2.4/SocketServer.py", line 463, in
process_request_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python2.4/SocketServer.py", line 254, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python2.4/SocketServer.py", line 521, in __init__
    self.handle()
  File "/usr/lib/python2.4/BaseHTTPServer.py", line 316, in handle
    self.handle_one_request()
  File "/usr/lib/python2.4/BaseHTTPServer.py", line 310, in
handle_one_request
    method()
  File "/usr/lib/python2.4/SimpleXMLRPCServer.py", line 441, in do_POST
    self.send_response(200)
  File "/usr/lib/python2.4/BaseHTTPServer.py", line 367, in send_response
    self.wfile.write("%s %d %s\r\n" %
  File "/usr/lib/python2.4/socket.py", line 256, in write
    self.flush()
  File "/usr/lib/python2.4/socket.py", line 243, in flush
    self._sock.sendall(buffer)
error: (32, 'Broken pipe')

Heavily parsed xend.log
[2006-11-28 19:53:26 xend] DEBUG (DevController:105) DevController:
writing {'domain': 'ExampleDomain', 'frontend':
'/local/domain/2/device/vbd/771', 'dev': 'hda3', 'state': '1', 'params':
'VolGroup00/LogVol01', 'mode': 'w', 'frontend-id': '2', 'type': 'phy'}
to /local/domain/0/backend/vbd/2/771.
[2006-11-28 19:53:26 xend.XendDomainInfo] DEBUG (XendDomainInfo:675)
Storing VM details: {'ssidref': '0', 'uuid':
'181bb390-efb4-255d-75d7-e35ad1f5c348', 'on_reboot': 'restart',
'start_time': '1164761606.34', 'on_poweroff': 'destroy', 'name':
'ExampleDomain', 'vcpus': '1', 'vcpu_avail': '1', 'memory': '64',
'on_crash': 'restart', 'image': "(linux (kernel
/boot/vmlinuz-2.6.16.29-xenU) (ramdisk /boot/initrd-2.6.9-34.ELsmp.img)
(ip :::::eth0:dhcp) (root '/dev/hda1 ro') (args 4))", 'maxmem':
'64'}                                                             
[2006-11-28 19:53:26 xend.XendDomainInfo] DEBUG (XendDomainInfo:700)
Storing domain details: {'console/ring-ref': '41460', 'console/port':
'2', 'name': 'ExampleDomain', 'console/limit': '1048576', 'vm':
'/vm/181bb390-efb4-255d-75d7-e35ad1f5c348', 'domid': '2',
'cpu/0/availability': 'online', 'memory/target': '65536',
'store/ring-ref': '41461', 'store/port':
'1'}                                    [2006-11-28 19:53:26
xend.XendDomainInfo] DEBUG (XendDomainInfo:881)
XendDomainInfo.handleShutdownWatch
[2006-11-28 19:53:26 xend.XendDomainInfo] WARNING (XendDomainInfo:823)
Domain has crashed: name=ExampleDomain id=2.
[2006-11-28 19:53:26 xend.XendDomainInfo] ERROR (XendDomainInfo:1496) VM
ExampleDomain restarting too fast (0.487512 seconds since the last
restart).  Refusing to restart to avoid loops.

Does this mean anything to anyone?

THanks,
Jim.

Michael Watters wrote:
> Jim Lynch wrote:
>> Error: Kernel image does not exist: /boot/vmlinuz-2.6.16.29-xenU
>> That didn't work.  It makes no sense that I would have to have a copy of
>> that kernel locally does it?  I thought that xen would look at the
>> configuration, the /etc/fstab on the CentOS system and try to load the
>> kernel from there.  After all, that's where install put it.  So xm isn't
>> finding it. Why?
> That's what I thought too but the kernel actually goes on the dom0
> system, the kernel MODULES need to be copied to the guest.  It makes
> sense if you think about it, xen can't boot a kernel it can't see.
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>
>
>


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.