FC6 initrd without xenblk?

I had to roll a custom initrd for 2.6.19-1.2911.6.5.fc6xen
which included
xenblk during boot:

[roothosting-3 ~]# mkinitrd -f --preload=xenblk
--with=xenblk /boot/initrd-2.6.19-1.2911.6.5.fc6xen.img.1
2.6.19-1.2911.6.5.fc6xen

The default initrd didn't load xenblk and thus domU didn't
have any block devices,
halting the boot process right in its tracks.

Is there a "better" way to do this for PVM under
FC6? (this example is Debian etch
DomU under FC6 Dom0.)

My config file:

[roothosting-3 ~]# cat /etc/xen/servers/test1
kernel = "/boot/vmlinuz-2.6.19-1.2911.6.5.fc6xen"
ramdisk =
"/boot/initrd-2.6.19-1.2911.6.5.fc6xen.img.1"
memory = 128
name = "test1"
vif = [ 'bridge=xenbr0.4' ]
disk = [ 'phy:Hosting3/XEN_test1_root,sda1,w',
'phy:Hosting3/XEN_test1_swap,sda2,w' ]
root = "/dev/sda1 ro"
on_crash = "preserve"

Thanks,



Adrian



--
Fedora-xen mailing list
Fedora-xenredhat.com
ht
tps://www.redhat.com/mailman/listinfo/fedora-xen

On Wed, 11 Apr 2007, Adrian Chadd wrote:

> I had to roll a custom initrd for
2.6.19-1.2911.6.5.fc6xen which included
> xenblk during boot:
>
> [roothosting-3 ~]# mkinitrd -f --preload=xenblk
--with=xenblk /boot/initrd-2.6.19-1.2911.6.5.fc6xen.img.1
2.6.19-1.2911.6.5.fc6xen
>
> The default initrd didn't load xenblk and thus domU
didn't have any block devices,
> halting the boot process right in its tracks.
>
> Is there a "better" way to do this for PVM
under FC6? (this example is Debian etch
> DomU under FC6 Dom0.)

No :(

Because the dom0 didnt need the drivers, they're not put in
the initrd for
the dom0, but it doesn't calculate in the fact we want to
use the same initrd
for the guests. I'm probably sounding like a broken record
asking for these
drivers in the default initrd for the xen kernel (which is
used for both
dom0 and guests).

Paul

-- 
Building and integrating Virtual Private Networks with
Openswan:
http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155

--
Fedora-xen mailing list
Fedora-xenredhat.com
ht
tps://www.redhat.com/mailman/listinfo/fedora-xen

On Wed, Apr 11, 2007, Paul Wouters wrote:

> > Is there a "better" way to do this for
PVM under FC6? (this example is Debian etch
> > DomU under FC6 Dom0.)
> 
> No :(
> 
> Because the dom0 didnt need the drivers, they're not
put in the initrd for
> the dom0, but it doesn't calculate in the fact we want
to use the same initrd
> for the guests. I'm probably sounding like a broken
record asking for these
> drivers in the default initrd for the xen kernel (which
is used for both
> dom0 and guests).

Thats really the case? I went looking for fc6 xen0 and xenU
kernels like there
was with FC5 but couldn't find it; I thought they'd then
"do the right thing."

Daniel, any chance of having at least xenblk in the fc6
initrd unless there's
also a seperate initrd shipped, or split dom0/domU kernels
like with FC5?

2c,


Adrian

--
Fedora-xen mailing list
Fedora-xenredhat.com
ht
tps://www.redhat.com/mailman/listinfo/fedora-xen

On Wed, Apr 11, 2007 at 11:15:05PM +0800, Adrian Chadd
wrote:
> On Wed, Apr 11, 2007, Paul Wouters wrote:
> 
> > > Is there a "better" way to do this
for PVM under FC6? (this example is Debian etch
> > > DomU under FC6 Dom0.)
> > 
> > No :(
> > 
> > Because the dom0 didnt need the drivers, they're
not put in the initrd for
> > the dom0, but it doesn't calculate in the fact we
want to use the same initrd
> > for the guests. I'm probably sounding like a
broken record asking for these
> > drivers in the default initrd for the xen kernel
(which is used for both
> > dom0 and guests).
> 
> Thats really the case? I went looking for fc6 xen0 and
xenU kernels like there
> was with FC5 but couldn't find it; I thought they'd
then "do the right thing."

The separate  xen0 / xenU kernels were old style
'monolithic' Xen builds which
turned off loadable modules for a large class of drivers.
This wasn't sustainable
long term where we're aiming to ultimately converge on a
single kernel image.
ie, with upstream paravirt-ops we ultimately won't even need
a special kernel-xen
for guest VMs - the regular 'kernel' will be able to
auto-detect that it is running
on baremetal, vs Xen, vs VMWare.  Getting Dom0 to use
paravirt-ops is a much harder
task, but it is still our long term goal - maintaining
multiple kernels is just
not at all sustainable - as demonstrated by frequent periods
where we have no
Xen update available to match baremetal :-(

So our long term goals of virtualization are to reduce &
eliminate the 'special 
cases' for dealing with virtualization.

> Daniel, any chance of having at least xenblk in the fc6
initrd unless there's
> also a seperate initrd shipped, or split dom0/domU
kernels like with FC5?

It is not going to happen. We provide a single kernel RPM,
and the initrd is 
auto-generated based on the hardware profile of the OS in
which the RPM is 
installed. Our recommendation is always to keep the DomU
kernel inside the 
DomU OS image and manage it with the normal update tools.
This gives a 
consistent management model across bare metal, Xen paravirt,
Xen fullvirt,
VMWare, KVM, QEMU - each OS manages its own bits.

Even beyond just the xennet/blk modules, there are plenty of
other non-hardware 
related kernel modules that a DomU may want to use - eg all
the IPTables addons,
so regardless of xenblk/net you'll almost certainly need the
kernel-xen RPM
installed inside the DomU regardless. With forthcoming
generations of CPUs
it will be possible to securly hand-off hardware devices to
DomUs too, still
further extends the set of kernel modules you want access to
in DomU. Thus
it is impossible to pre-generate a initrd in Dom0 that will
be suitable for
general use in DomU.

That all said - and as has been pointed out previously - if
people still wish
to have kernel/initrd located in Dom0, and know exactly
which specific set
of kernel modules their guest will use, they always the
option of creating
another initrd-domU-2.6.19-XXX.img using the regular
mkinitrd tools.


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

--
Fedora-xen mailing list
Fedora-xenredhat.com
ht
tps://www.redhat.com/mailman/listinfo/fedora-xen

On Wed, 11 Apr 2007, Daniel P. Berrange wrote:

> > Daniel, any chance of having at least xenblk in
the fc6 initrd unless there's
> > also a seperate initrd shipped, or split dom0/domU
kernels like with FC5?
>
> It is not going to happen. We provide a single kernel
RPM, and the initrd is
> auto-generated based on the hardware profile of the OS
in which the RPM is
> installed.

The OS can be detected as being a dom0 with the xen
hypervisor underneath
it, and then include xenblk in the initrd creation for use
by the guests.

> Our recommendation is always to keep the DomU kernel
inside the
> DomU OS image and manage it with the normal update
tools. This gives a

In real life, people need to maintain old images like
FC3/4/5, old Debian's,
Centos/RHEL and what not. Those cannot install kernel-xen
images inside
them, so your "solution" does not work in real
life.

> installed inside the DomU regardless. With forthcoming
generations of CPUs
> it will be possible to securly hand-off hardware
devices to DomUs too, still
> further extends the set of kernel modules you want
access to in DomU. Thus
> it is impossible to pre-generate a initrd in Dom0 that
will be suitable for
> general use in DomU.

This argument is wrong.

Most, if not all, of those device drivers can be obtained
from the
guest's /lib/modules. It is only xenblk and raid and ext3
that we need
to read the other modules from the virtual disk. All the
other hardware
drivers can be loaded later on, and do not require to be in
the ramdisk.
So no, even if handing over other PCI devices or what not, I
don't have
a problem with the driver not being in the initrd.

> That all said - and as has been pointed out previously
- if people still wish
> to have kernel/initrd located in Dom0, and know exactly
which specific set

You are phrasing this rather wrong. I don't "wish
it", I "require it" to
run old OS'es with xen-capable newer kernels.

> of kernel modules their guest will use, they always the
option of creating
> another initrd-domU-2.6.19-XXX.img using the regular
mkinitrd tools.

And you are making us do this for *every* kernel you
release, simply because
of the refusal to load a single driver. A driver that at
most will be
unused, which if redhat wants, it could unload in
rc.sysvinit, and which
takes up 22980 bytes of kernel memory on my xen server,
which are all
loaded with 4GB of ram to provide memory to many guests to
begin with.

All I want is per default to be able to read the virtual
disk using xenblk
so i can load the rest of the drivers. You're being
fundamentalist about
this issue.

Paul

--
Fedora-xen mailing list
Fedora-xenredhat.com
ht
tps://www.redhat.com/mailman/listinfo/fedora-xen