All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: James Dingwall <james-xen@dingwall.me.uk>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: pygrub/hvm boot with alternate script= for block devices
Date: Mon, 21 Jan 2013 13:03:15 +0100	[thread overview]
Message-ID: <50FD2E83.6090505@citrix.com> (raw)
In-Reply-To: <1358765283.3279.170.camel@zakaz.uk.xensource.com>

On 21/01/13 11:48, Ian Campbell wrote:
> On Mon, 2013-01-21 at 10:19 +0000, Roger Pau Monne wrote:
>> On 21/01/13 11:01, Ian Campbell wrote:
>>> On Mon, 2013-01-21 at 09:56 +0000, Roger Pau Monné wrote:
>>>> On 19/01/13 16:46, James Dingwall wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am doing some experimentation with xen and Ceph and have a problem
>>>>> booting my guest when my disk = [] uses an alternate block script.
>>>>> Installation from a .iso was ok since the boot device was a file but 
>>>>> now
>>>>> trying to boot from the rbd neither the hvmbuilder or pygrub can start
>>>>> as they treat the first value after target= as the /dev node to try and
>>>>> use.
>>>>
>>>> Yes, this is known problem which I'm trying to solve with this series:
>>>>
>>>> http://lists.xen.org/archives/html/xen-devel/2012-12/msg01753.html
>>>>
>>>>>
>>>>> My disk parameter looks like:
>>>>> disk = [ 'format=raw, script=block-rbd, vdev=xvda, access=w,
>>>>> target=image=ubuntu-test' ]
>>>>>
>>>>> In the pygrub log:
>>>>> OSError: [Errno 2] No such file or directory: 'image=ubuntu-test'
>>>>>
>>>>> and there is a similar error trying an HVM boot.
>>>>>
>>>>> My block-rbd script parses the value passed after target= to
>>>>> dynamically rbd map the image and then call the write_dev function from
>>>>> block-common.sh to save the corresponding /dev name in xenstore.
>>>>> According to the logging that I have in my block-rbd script this isn't
>>>>> even called before pygrub is executed.
>>>>
>>>> The only solution right now will be to use PV guests and boot directly
>>>> with the kernel (no pygrub)
>>>
>>> Does commenting out the stat & check in the short term allow things to
>>> work well enough for James' purposes?
>>
>> Current hotplug scripts don't have any need to write the dev in
>> xenstore, they only need to write the device major:minor in the
>> physical-device xenstore backend entry. The only way to solve this (with
>> current hotplug scripts) will be to call libxl_device_disk_add earlier
>> on (before pygrub), fetch "physical-device" from xenstore and translate
>> that back into the physical device it points to, and overwrite pdev_path
>> in libxl_device_disk struct with this value.
> 
> OK, I think I follow. Presumably a similar hack would be needed to make
> the local_attach interface do something useful here too.
> 
>> I would rather wait for the new interface to be finished rather than
>> adding this "hack" to libxl.
> 
> Fair enough.
> 
> In the meantime I suppose James could work around this by logging into
> rdb manually (or in a script) before starting the domain and
> specifying /dev/rdbN in the guest config?

Yes, I guess that's what most high-level toolstacks (like libvirt or
XAPI) do for supporting this kind of backends.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2013-01-21 12:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-19 15:46 pygrub/hvm boot with alternate script= for block devices James Dingwall
2013-01-21  9:56 ` Roger Pau Monné
2013-01-21 10:01   ` Ian Campbell
2013-01-21 10:19     ` Roger Pau Monné
2013-01-21 10:48       ` Ian Campbell
2013-01-21 12:03         ` Roger Pau Monné [this message]
2013-01-21 10:14   ` James Dingwall
2013-01-21 10:26     ` Roger Pau Monné
2013-01-22  8:50       ` James Dingwall
2013-01-22  9:05         ` Roger Pau Monné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50FD2E83.6090505@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=james-xen@dingwall.me.uk \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.