domUloader kernel command line arguments?

domUloader kernel command line arguments?

[John Byrne]

domUloader potentially makes my life a lot easier, but from experiments 
and looking at the code, it doesn't seem like there is any way to pass 
kernel command line arguments with it. Am I just missing something?

Thanks,

John Byrne

Re: domUloader kernel command line arguments?

[Kurt Garloff]

[-- Attachment #1.1.1: Type: text/plain, Size: 932 bytes --]

Hi John,

On Thu, Mar 09, 2006 at 06:29:57PM -0800, John Byrne wrote:
> domUloader potentially makes my life a lot easier, but from experiments 
> and looking at the code, it doesn't seem like there is any way to pass 
> kernel command line arguments with it. Am I just missing something?

No, it has been an oversight on the way domUloader was integrated
into xen. The XendBootloader assumes that the bootloader would
pass the kernel command line parameters back as (arg ...).
domUloader does not do that, as it does not use an external
configuration file where these would be specified.

Attached patch addresses this: If the bootloader does NOT return
anything as args, the values from the config file (ip, boot, extra)
will be filled in.

You need to apply this on top of the other domUloader patches.
Let me know if this addresses your problem.

Best,
-- 
Kurt Garloff, Head Architect Linux, Novell Inc.

[-- Attachment #1.1.2: xen-create-args.diff --]
[-- Type: text/x-patch, Size: 3047 bytes --]

From: Kurt Garloff <garloff@suse.de>
Subject: Command line parameters with domUloader.py

The bootloader framework expected the bootloader to return
kernel command line paramters as (args '...'). pygrub does this,
but domUloader does not have such info. Thus fill in ip,root,args
in case it has been left empty by the bootloader. Also make sure,
these values survive a reboot.

Signed-off-by: Kurt Garloff <garloff@suse.de>

--- xen/xend/XendDomainInfo.py.orig	2006-02-27 17:03:06.000000000 +0100
+++ xen/xend/XendDomainInfo.py	2006-03-07 10:03:31.000000000 +0100
@@ -1507,6 +1507,14 @@ class XendDomainInfo:
         # if we're restarting with a bootloader, we need to run it
         blcfg = None
         config = self.sxpr()
+	# save filled in values ip, root, args
+	image= sxp.child_value(config, "image")
+	ip   = sxp.child_value(image, "ip")
+	root = sxp.child_value(image, "root")
+	args = sxp.child_value(image, "args")
+	log.debug("bootloader: saved (ip %s) (root %s) (args %s)" \
+		% (ip, root, args))
+	# Look for disks
         devices = sxp.children(config, "device")
         # bootloader expects disks in config file format:
         # [(uname, dev, mode, backend), (...), ...]
@@ -1532,6 +1540,16 @@ class XendDomainInfo:
             msg = "Had a bootloader specified, but can't find disk"
             log.error(msg)
             raise VmError(msg)
+        # If bootloader has not filled in args, used saved values
+        # see xm/create.py: run_bootloader().
+        if sxp.child_value(blcfg, "args") is None:
+            if ip:
+                blcfg.append(['ip', ip])
+            if root:
+                blcfg.append(['root', root])
+            if args:
+                blcfg.append(['args', args])
+
         self.info['image'] = sxp.to_string(blcfg)
 
 
--- xen/xm/create.py.orig	2006-02-27 17:03:06.000000000 +0100
+++ xen/xm/create.py	2006-03-07 09:17:57.000000000 +0100
@@ -563,8 +563,21 @@ def run_bootloader(vals):
     if not vals.disk:
         err("No disks configured and boot loader requested")
 
-    return bootloader(vals.bootloader, vals.disk, not vals.console_autoconnect,
-                      vals.vcpus, vals.bootentry, vals.root)
+    config_image = bootloader(vals.bootloader, vals.disk, 
+                              not vals.console_autoconnect,
+                              vals.vcpus, vals.bootentry, vals.root)
+    # If bootloader does not fill in "args", we should use the
+    # values from the config file.
+    if sxp.child_value(config_image, "args") is None:
+        if vals.cmdline_ip:
+            cmdline_ip = strip('ip=', vals.cmdline_ip)
+            config_image.append(['ip', cmdline_ip])
+        if vals.root:
+            cmdline_root = strip('root=', vals.root)
+            config_image.append(['root', cmdline_root])
+        if vals.extra:
+            config_image.append(['args', vals.extra])
+    return config_image
 
 def make_config(vals):
     """Create the domain configuration.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: domUloader kernel command line arguments?

[Matt Ayres]

Kurt Garloff wrote:

> 
> You need to apply this on top of the other domUloader patches.
> Let me know if this addresses your problem.

On a side note, WILL domUloader ever be integrated into Xen? I much 
prefer it over pygrub as it will read from a filesystem (vs partitions) 
and relies on the host FS support (so JFS/XFS are no problem).

I know there were some complaints to the implementation, but is work 
being done to make sure that domUloader does not die as a project?

Thanks,
Matt

Re: Re: domUloader kernel command line arguments?

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 1554 bytes --]

Hi Matt,

On Fri, Mar 10, 2006 at 09:20:21AM -0500, Matt Ayres wrote:
> Kurt Garloff wrote:
> 
> >
> >You need to apply this on top of the other domUloader patches.
> >Let me know if this addresses your problem.
> 
> On a side note, WILL domUloader ever be integrated into Xen? 

Don't know. I definitely would like to see it integrated.
I haven't been able to follow the list too well the last weeks, so
I'm not aware of the latest discussion status on this.

> I much 
> prefer it over pygrub as it will read from a filesystem (vs partitions) 
> and relies on the host FS support (so JFS/XFS are no problem).

It should not come as a surprise that I like it as well :-)

> I know there were some complaints to the implementation, 

I'm aware of two complaints
(1) security concerns (you _mount_ the FS in dom0)
(2) the use of kpartx from multipath-tools which seems to be missing
    from some ancient distros

Anything else you are aware of?

(1) is a feature and it's the reason why we probably will have pygrub
    coexist with domUloader :-(
(2) we could help, by using fdisk -l and losetup rather than kpartx
    if the latter is missing; though fdisk -l would limit the supported
    partition tables to DOS ones.

> but is work 
> being done to make sure that domUloader does not die as a project?

Well, domUloader is shipped and used by Novell.
I guess I should set up a project page somewhere in case we can't
get it included in Xen.

Regards,
-- 
Kurt Garloff, Head Architect Linux, Novell Inc.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: domUloader kernel command line arguments?

[Charles Coffing]

>>> On Fri, Mar 10, 2006 at  8:25 AM, in message
<20060310152554.GK5766@tpkurt.garloff.de>, Kurt Garloff
<garloff@suse.de> wrote: 
> (2) we could help, by using fdisk -l and losetup rather than kpartx
>     if the latter is missing; though fdisk -l would limit the
supported
>     partition tables to DOS ones.

BTW:  lomount in the xen tree is working pretty well for me now; it
automates those two steps.

Re: Re: domUloader kernel command line arguments?

[Matt Ayres]

Kurt Garloff wrote:

> 
>> but is work 
>> being done to make sure that domUloader does not die as a project?
> 
> Well, domUloader is shipped and used by Novell.
> I guess I should set up a project page somewhere in case we can't
> get it included in Xen.
> 

That is all I needed to hear.  Thanks.

In the case pygrub is the one and only boot loader then that means it 
must supersede domUloader in features.

Thanks!
Matt

RE: Re: domUloader kernel command line arguments?

[Ian Pratt]

> > I know there were some complaints to the implementation,
> 
> I'm aware of two complaints
> (1) security concerns (you _mount_ the FS in dom0)

This is certainly a fair concern. I'd wager most linux filesystem code
can quite easily be subverted by a maliciously crafted on-disk bit
pattern.

> (2) the use of kpartx from multipath-tools which seems to be missing
>     from some ancient distros

Not so ancient... I've never managed to make kpartx work on anything
other than a SuSE distro.

> Anything else you are aware of?
> 
> (1) is a feature and it's the reason why we probably will have pygrub
>     coexist with domUloader :-(
> (2) we could help, by using fdisk -l and losetup rather than kpartx
>     if the latter is missing; though fdisk -l would limit the 
> supported
>     partition tables to DOS ones.

I'm not a fan of pygrub as that requires very new versions of the
filesystem libraries (to support "open2" and hence patition table
offsets).

Perhaps we should be considering having both in tree? I've somewhat lost
track of where we are in the discussion as regards to support for Sun's
UFS. Could someone please generate a summary?

Thanks,
Ian

Re: Re: domUloader kernel command line arguments?

[John Levon]

On Fri, Mar 10, 2006 at 11:41:40PM -0000, Ian Pratt wrote:

> I'm not a fan of pygrub as that requires very new versions of the
> filesystem libraries (to support "open2" and hence patition table
> offsets).
> 
> Perhaps we should be considering having both in tree? I've somewhat lost
> track of where we are in the discussion as regards to support for Sun's
> UFS. Could someone please generate a summary?

I sent a proposal regarding the configuration format for bootloaders.
Jeremy had some issues that centered around:

o he didn't like the format I suggested. I proposed one closer to that
  currently provided, but haven't had a response to that yet

o he believes that the current "supply a Python module" interface to
  file systems is OK and that all domu's are expected to provide GPLed
  sources (not necessarily a huge problem for us but I do worry about
  other situations in the future).

o he pointed out that for Fedora/RHEL, the current solution is
  sufficient.

o he appeared to be against the notion of enabling other boot loaders
  beyond the current (limited) interface

Apologies if I've mis-represented anything here; Jeremy's posts are not
available in the mail archives.

There was general agreement that a solution that defers all
configuration to the domu such as grub xen support was the best
long-term option. I do not think that this affects the current
discussion, however.

I believe the biggest issue that needs to be resolved is where the
filesystem-reading code belongs. I've been advocating that the relevant
dom0 systems provide a 'readfs' binary that defer to particular
implementations for each file system. This would help take the
maintenance burden off the Xen project itself, and centralise all FS
handling in one sensible place. (In particular, such a project could
easily ship with its own ext2fs library so the open2 support issue goes
away for now). So far this idea does not seem popular, but I've not
received any details as to why. I believe that an opaque interface
provided by a command line binary is safer in the mid/long-term than
requiring a Python module to be delivered, mainly due to the fact that
Python is still changing incompatibly, and the stability of the internal
pygrub API is under doubt (Jeremy has mentioned he wants to make changes
already).

My changes should also work well with Kurt's loader which Novell are
using. As a by-product it resolves some of the problems with the
bootloader interface that domUloader has.

I hope I've not missed anything important here; corrections are welcome.

regards,
john