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