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

Re: [Xen-users] Boot loader didn't return any data!

On Fri, 2012-02-17 at 09:37 -0500, James Pifer wrote:
> I'm having a lot of problems with some pv domU's getting "Boot loader
> didn't return any data!" when trying to start them. Some will start fine
> on one server, but if I migrate to another server in the pool it will
> not start if it is shutdown. (Live Migrate works fine.) 
> Here's some background. 
>       * Pooled servers are sles11sp1 with kernel pcalakxen07
>       * xen version xen-4.0.2_21511_04-0.5.1
>       * VMs are sles11sp1 and some sles10
>       * Disks are provided by an Active/Active SAN
>       * Servers are using multipath
>       * Third party software (Convirture Enterprise) controls access to
>         disk to prevent contention for the same disk
>       * Live Migrate on functioning domU's works fine
>       * If domU is then shut down, it may not start back up
> I can add the disks to an hvm domU and boot off system-rescue CD I can
> mount the ext3 file systems fine. So I'm trying to find out what
> domUloader does when it tries to boot a pv domU. 
> If I look at it with kpartx I get:
> xen07:~ # kpartx -l /dev/mapper/360030d900825cc06b07a721f577b3f62
> 360030d900825cc06b07a721f577b3f62p1 : 0 4194304 
> /dev/mapper/360030d900825cc06b07a721f577b3f62 2048
> 360030d900825cc06b07a721f577b3f62p2 : 0 37746688 
> /dev/mapper/360030d900825cc06b07a721f577b3f62 4196352
> xen07:~ # kpartx -a /dev/mapper/360030d900825cc06b07a721f577b3f62
> device-mapper: create ioctl failed: Device or resource busy
> create/reload failed on 360030d900825cc06b07a721f577b3f62p1
> device-mapper: create ioctl failed: Device or resource busy
> create/reload failed on 360030d900825cc06b07a721f577b3f62p2
> If I do this for a VM that I know 100% certain will boot, kpartx -a adds
> the mappings fine. 
> How can I determine why a physical device is locked or busy and who has
> control of it?
> Maybe I have a multipath issue? I have a ticket open with Novell and
> with my SAN vendor, but so far I'm not making much progress. 

I'm 99% certain that the problem I have is because kpartx cannot create
the mapping for these physical devices. Every one of them that I have
tested fails this test. 

The question is why? Why are these devices locked? I have no issue
migrating a domU to the same server, with the same disk, so why does
kpartx have a problem with? It's also not consistent with only one
server or domU. Some work on some servers and not others. 

Any ideas?


Xen-users mailing list



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