Fedora xen - May 2007 - [patch] GUI for spacifying additional kernel parameters

Hello list,
I needed to use additional kernel parameters when installing a Xen 
guest. I was testing modifications of anaconda.

This patch provides a page where the user can supply any parameters that 
should be passed to the kernel. Write the parameters as you would do it 
on the command line for a physical machine.
The new page is shown after settings for paravirtualized install.

Changes are in vmm-create.glade and virtManager/create.py.

Q: Why there is an option to pass additional kernel parameters only for 
paravirtualized installs? Is this possible for fully virtualized installs?

NB: I have tested this with a backported changes for the version I have 
installed on my system but it should be working in devel version too.

Greetings,
Alexander.

On Wed, May 09, 2007 at 02:46:44PM +0200, Alexander Todorov
wrote:
> Hello list,
> I needed to use additional kernel parameters when installing a Xen 
> guest. I was testing modifications of anaconda.
Could you give an example of the kind of kernel parameters you are
needing to provide. Traditionally the most common need was for various
hardware workarounds, which shouldn''t be neccessary in paravirt case.
So I''d be interested to know what you''re using and thus figure
out if
there is a higher level UI we could provide to accomplish the same
thing instead of kernel params.
> This patch provides a page where the user can supply any parameters that 
> should be passed to the kernel. Write the parameters as you would do it 
> on the command line for a physical machine.
> The new page is shown after settings for paravirtualized install.
> 
> Changes are in vmm-create.glade and virtManager/create.py.
If we do decide add such a UI it shouldn''t be a separate page - simply
another text box below the existing kickstart URL field. 
> Q: Why there is an option to pass additional kernel parameters only for 
> paravirtualized installs? Is this possible for fully virtualized installs?
With Xen no - the way full virt works with Xen is that we run an actual
BIOS. This BIOS boots off a CDROM so there''s no way to provide any
kernel
parameters there. Of course the syslinux / grub screen that the BIOS
launches would let you enter kernel parameters fairly easily.

With QEMU/KVM, fullvirt can either boot off a CDROM, or directl from a
kernel+initrd pair. In the latter case we''d be able to provide kenrel
parameters in same way as Xen paravirt. We currently don''t allow the
use of kernel+initrd in the UI for QEMU/KVM though because it has bugs
which cause it to hang. 

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

Hello,
Here is a revised version:
removed new page, moved widgets to PVInstall page.
A little bit of code cleanup.


Daniel P. Berrange wrote:
> ''hg export'' makes reviewing via email a little easier if
its just simple
> patches. I should update the README really :-)
>
Thanks for this hint. I am mercurial newbie.
Will use it next time.
> Regards,
> Dan.

On Thu, 10 May 2007 15:54:54 +0100 Daniel wrote:
DPB> On Wed, May 09, 2007 at 02:46:44PM +0200, Alexander Todorov wrote:
DPB> > I needed to use additional kernel parameters when installing a Xen 
DPB> > guest. I was testing modifications of anaconda.
DPB> 
DPB> Could you give an example of the kind of kernel parameters you are
DPB> needing to provide. Traditionally the most common need was for various
DPB> hardware workarounds, which shouldn''t be neccessary in paravirt
case.

I''ll be glad to give you an two examples that I''ve just run
into...

1) noirqdebug ; to keep the domU from _disabling_ a shared IRQ used by a
devices passed through via pciback, thus hosing the same IRQ for the dom0 (not
a good thing when the shared IRQ is for your IDE controller in the dom0).

2) swiotlb=force to eliminate the kernel BUG when the domU accesses the
device passed through via pciback

Daniel P. Berrange wrote:
> On Wed, May 09, 2007 at 02:46:44PM +0200, Alexander Todorov wrote:
>   
>> Hello list,
>> I needed to use additional kernel parameters when installing a Xen 
>> guest. I was testing modifications of anaconda.
>>     
>
> Could you give an example of the kind of kernel parameters you are
> needing to provide. Traditionally the most common need was for various
> hardware workarounds, which shouldn''t be neccessary in paravirt
case.
> So I''d be interested to know what you''re using and thus
figure out if
> there is a higher level UI we could provide to accomplish the same
> thing instead of kernel params.
>   
If I don''t have a dhcp server in the network and my kickstart file is 
located on an http server in the network, I have to pass network 
parameters to the kernel before starting off.
>   
>> This patch provides a page where the user can supply any parameters
that
>> should be passed to the kernel. Write the parameters as you would do it
>> on the command line for a physical machine.
>> The new page is shown after settings for paravirtualized install.
>>
>> Changes are in vmm-create.glade and virtManager/create.py.
>>     
>
> If we do decide add such a UI it shouldn''t be a separate page -
simply
> another text box below the existing kickstart URL field. 
>
>   
>> Q: Why there is an option to pass additional kernel parameters only for
>> paravirtualized installs? Is this possible for fully virtualized
installs?
>>     
>
> With Xen no - the way full virt works with Xen is that we run an actual
> BIOS. This BIOS boots off a CDROM so there''s no way to provide any
kernel
> parameters there. Of course the syslinux / grub screen that the BIOS
> launches would let you enter kernel parameters fairly easily.
>
> With QEMU/KVM, fullvirt can either boot off a CDROM, or directl from a
> kernel+initrd pair. In the latter case we''d be able to provide
kenrel
> parameters in same way as Xen paravirt. We currently don''t allow
the
> use of kernel+initrd in the UI for QEMU/KVM though because it has bugs
> which cause it to hang. 
>
> Regards,
> Dan.
>