Xen users - Dec 2006 - usage of the extra parameter in vm configs

After using xen for quite some time, I just start to wonder what the
"extra" value in the vm config is good for.

The example configs explain it can be used to set the runlevel - but i
never removed this option, so it was alwas  there and set to the
default 4 from the example, and still all my debian domUs start fine
in runlevel 2 as usual.
So I wonder if there''s some real-world example of using the extra
variable.

Henning

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

>After using xen for quite some time, I just start to wonder what the
>"extra" value in the vm config is good for.
extra is just a placeholder for misc kernel arguments. Any random arguments 
you might want to pass through can be specified there and they''ll get 
tacked onto the end of the kernel command line. These might be special 
options for kernel behaviour, or for some driver, or to be parsed from 
/proc/cmdline by a userspace program within the guest OS.

It doesn''t really have a specific purpose. :-)

We''d actually been talking about replacing the current
"root=", "extra="
etc. arguments with a single "cmdline=" which would contain the entire
kernel commandline - in the same way that a normal bootloader might. This 
would make the process of setting the command line a little more 
transparent.

It''s certainly safe to not use it if not required...

Does this answer your question satisfactorily?

HTH,
Cheers,
Mark
>The example configs explain it can be used to set the runlevel - but i
>never removed this option, so it was alwas  there and set to the
>default 4 from the example, and still all my debian domUs start fine
>in runlevel 2 as usual.
>So I wonder if there''s some real-world example of using the extra
variable.
>
>Henning
>
>_______________________________________________
>Xen-users mailing list
>Xen-users@lists.xensource.com
>http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 30 Dec 2006 15:18:20 +0000, M.A. Williamson <maw48@cam.ac.uk>
wrote:
> We''d actually been talking about replacing the current
"root=", "extra="
> etc. arguments with a single "cmdline=" which would contain the
entire
> kernel commandline - in the same way that a normal bootloader might.
I think that''s a good idea, because that was the next question I
wanted to ask: what''s the difference between the root variable (which
in all examples not only contains the root, but alo the additional
argument "ro") and extra, and why should I not  just add more
arguments to the root variable and leave the extra arg empty?

As I understand it now, theres no big semantic difference between
both, and they get actually "glued together" and handed over to the
guest kernel at domain creation time.
> Does this answer your question satisfactorily?
Yes, thanks a lot!

Henning

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

>On 30 Dec 2006 15:18:20 +0000, M.A. Williamson <maw48@cam.ac.uk>
wrote:
>> We''d actually been talking about replacing the current
"root=", "extra="
>> etc. arguments with a single "cmdline=" which would contain
the entire
>> kernel commandline - in the same way that a normal bootloader might.
>
>I think that''s a good idea, because that was the next question I
>wanted to ask: what''s the difference between the root variable
(which
>in all examples not only contains the root, but alo the additional
>argument "ro") and extra, and why should I not  just add more
>arguments to the root variable and leave the extra arg empty?
You could. Or you could stick them all in the "extra" argument. The
only
real reason that the variables are done this way is that it decouples the 
user from the realities of Linux a little... Additional variables used to 
be used to pass IP / NFS root information on the command line but I''m
not
sure if this is still done...

The config file parser isn''t *very* aware of how Linux command line
syntax
works. At some stage it may be useful to make it more aware, for purposes 
of providing more helpful configuration warnings - however, this still 
doesn''t really require the separate variables.

Out of interest, would anybody on the users list object to a general shift 
towards supplying the whole command line in one variable, rather than 
piecemeal in specially named fields? We wouldn''t have to break
backwards
compatibility to do this...

Cheers,
Mark
>As I understand it now, theres no big semantic difference between
>both, and they get actually "glued together" and handed over to
the
>guest kernel at domain creation time.
>
>> Does this answer your question satisfactorily?
>
>Yes, thanks a lot!
>
>Henning
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 30 Dec 2006 15:53:35 +0000, M.A. Williamson <maw48@cam.ac.uk>
wrote:
> [...]
> You could. Or you could stick them all in the "extra" argument.
The only
> real reason that the variables are done this way is that it decouples the
> user from the realities of Linux a little... Additional variables used to
> be used to pass IP / NFS root information on the command line but
I''m not
> sure if this is still done...
yeah, nfs_root and dhcp also are transferred to the kernel command
line. Don''t know about the others.
> The config file parser isn''t *very* aware of how Linux command
line syntax
> works. At some stage it may be useful to make it more aware, for purposes
> of providing more helpful configuration warnings - however, this still
> doesn''t really require the separate variables.
Yes, it might look simpler for unexperienced users if they have all
the dhcp, root, ... variables, and enter exactly one value in each,
and experienced users with special needs can use "extra" for
everything special they need.
> Out of interest, would anybody on the users list object to a general shift
> towards supplying the whole command line in one variable, rather than
> piecemeal in specially named fields?
I wouldn''t mind.  As said, singeling them out looks easier maybe. (for
example new users don''t have to search a long "extra" line,
but can be
pointed to the single root variable for adjusting a boot partition if
needed.

I think most important and sufficient would be to document it clear in
xm create --help_config and man xmdomain.cfg what is now only
documented in this thread.

Henning

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

M.A. Williamson wrote:
> Out of interest, would anybody on the users list object to a general
> shift towards supplying the whole command line in one variable, rather
> than piecemeal in specially named fields? We wouldn''t have to
break
> backwards compatibility to do this...
I''d prefer that they be consolidated, as well.  As you said, the ip,
extra, etc. variables assume that the guest is Linux.  That is obviously
not always the case.  Having one generic cmdline variable would be
generic enough and keep all of the relevant information in one location.
 Simplifying the config file parsing would also be nice for future
automated tools.

-- 
Christopher G. Stach II


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

On 12/31/06, Christopher G. Stach II <cgs@ldsys.net>
wrote:
> I''d prefer that they be consolidated, as well.  As you said, the
ip,
> extra, etc. variables assume that the guest is Linux.  That is obviously
> not always the case.  Having one generic cmdline variable would be
> generic enough and keep all of the relevant information in one location.
>  Simplifying the config file parsing would also be nice for future
> automated tools.
Only one thing comes to my mind: at least ip (not sure which others)
is used for setting up the routes in a routed networking setup, so it
must be kept. Or parsed from the new single commandline variable -
which gets hard when different OSes use different ways to give an ip
on command line. Or worse, if you don''t set it on the commandline,
you''d be forced to still write the command line, because it''s
parsed
for routing.

But when making "ip" indepenedent from the kernel command line, those
users that use routed networking and a static ip given at the kernel
command line, have to set the same information in two places. But I
think that''s acceptable.

Henning

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