7:49 p.m.
http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7...
The way it works is to bundle the complete ISO image inside the initrd.
The kernel and (bloated) initrd are downloaded using PXE in the normal
way, and the init script finds and loopback-mounts the ISO image and
booting continues as normal.
Wow. I don't mean to offend, but this seems like an incredibly bad way
of doing this. Isn't this really slow in the boot up because you must
wait for the entire ISO to download? It also requires the client to
have more than enough RAM to have the entire ISO in memory? It sounds
like the entire memory used by the ISO remains unavailable to the booted
system.
I need something similar to boot read-only OS images over PXE boot for
LTSP. Upstream LTSP5 uses nbd to serve a raw squashfs image as a
network block device, which means only a tiny bit needs to be in the
initrd and very little memory overhead. Parts of the read-only image
are streamed over the network on demand.
I'm waiting on Jeremy to get back regarding a long-term plan for
supporting mayflower-like things within mkinitrd itself. NBD support
was not accepted into mkinitrd because it would rely upon mayflower-like
functionality to do right.
Warren Togami
wtogami(a)redhat.com
9:16 p.m.
Warren Togami wrote:
http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7...
> The way it works is to bundle the complete ISO image inside the initrd.
> The kernel and (bloated) initrd are downloaded using PXE in the normal
> way, and the init script finds and loopback-mounts the ISO image and
> booting continues as normal.
Wow. I don't mean to offend, but this seems like an incredibly bad way
of doing this. Isn't this really slow in the boot up because you must
wait for the entire ISO to download? It also requires the client to
have more than enough RAM to have the entire ISO in memory? It sounds
like the entire memory used by the ISO remains unavailable to the booted
system.
Well, it depends on your definition of "bad". For the purposes I
originally wrote it for, the ISO is going to be fairly small (~70MB or
less), and the target machines will have a lot of memory. So for that
situation, it works well enough, doesn't waste an appreciable amount of
memory, and fits into existing tools fairly easily.
I need something similar to boot read-only OS images over PXE boot for
LTSP. Upstream LTSP5 uses nbd to serve a raw squashfs image as a
network block device, which means only a tiny bit needs to be in the
initrd and very little memory overhead. Parts of the read-only image
are streamed over the network on demand.
The problem with this is the same problem that a NFS/iSCSI root have;
namely, that you have to setup another service alongside the PXE to get
the data over. That increases the server-side setup complexity,
something we are hoping to keep to a minimum with oVirt.
That's not to say that the method probably isn't preferable, in general,
however. And it's definitely something that we can look at doing in the
future. I'll have to take a closer look at the LTSP stuff at some point.
Chris Lalancette
9:33 p.m.
Chris Lalancette wrote:
Warren Togami wrote:
>
http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7...
>> The way it works is to bundle the complete ISO image inside the initrd.
>> The kernel and (bloated) initrd are downloaded using PXE in the normal
>> way, and the init script finds and loopback-mounts the ISO image and
>> booting continues as normal.
> Wow. I don't mean to offend, but this seems like an incredibly bad way
> of doing this. Isn't this really slow in the boot up because you must
> wait for the entire ISO to download? It also requires the client to
> have more than enough RAM to have the entire ISO in memory? It sounds
> like the entire memory used by the ISO remains unavailable to the booted
> system.
Well, it depends on your definition of "bad". For the purposes I
originally wrote it for, the ISO is going to be fairly small (~70MB or
less), and the target machines will have a lot of memory. So for that
situation, it works well enough, doesn't waste an appreciable amount of
memory, and fits into existing tools fairly easily.
Ah, I didn't realize that you were using livecd-tools and mayflower for
a rescue or install type image. ~70MB really isn't so bad, and you are
right about one less service to configure being a benefit.
Warren Togami
wtogami(a)redhat.com
9:42 p.m.
On Sun, Feb 17, 2008 at 10:33:40PM -0500, Warren Togami wrote:
Chris Lalancette wrote:
>Warren Togami wrote:
>>http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7c5fdfb8af45892f419c13
>>>The way it works is to bundle the complete ISO image inside the initrd.
>>>The kernel and (bloated) initrd are downloaded using PXE in the normal
>>>way, and the init script finds and loopback-mounts the ISO image and
>>>booting continues as normal.
>>Wow. I don't mean to offend, but this seems like an incredibly bad way
>>of doing this. Isn't this really slow in the boot up because you must
>>wait for the entire ISO to download? It also requires the client to
>>have more than enough RAM to have the entire ISO in memory? It sounds
>>like the entire memory used by the ISO remains unavailable to the booted
>>system.
>
>Well, it depends on your definition of "bad". For the purposes I
>originally wrote it for, the ISO is going to be fairly small (~70MB or
>less), and the target machines will have a lot of memory. So for that
>situation, it works well enough, doesn't waste an appreciable amount of
>memory, and fits into existing tools fairly easily.
Ah, I didn't realize that you were using livecd-tools and mayflower for
a rescue or install type image. ~70MB really isn't so bad, and you are
right about one less service to configure being a benefit.
It is not technically a rescue or an install image. The so called 'managed
nodes' simply run guest VMs & are effectively stateless. You just boot up
the minimal image containing only the libvirt daemon and enough utils to
bring up networking and login to iSCSI targets. Once up it connects to the
admin node and waits to be told to run guest VMs. All the VM's storage and
any persistent config is off on iSCSI or in the admin node. With such a
specific application use case & controlled environment is the perfect
stateless host scenario. The admin will never even login to a managed node,
if it breaks just deploy a new node - each node is totally disposable at
any time (well bar a little VM downtime, or pre-emptive migration).
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 -=|
9:35 p.m.
/me wonders if tftp-server supports range requests. Then you could have
a really slow and unreliable loopback mount over tftp. =)
Warren
9:36 p.m.
On Sun, Feb 17, 2008 at 10:16:58PM -0500, Chris Lalancette wrote:
Warren Togami wrote:
>
http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7...
>> The way it works is to bundle the complete ISO image inside the initrd.
>> The kernel and (bloated) initrd are downloaded using PXE in the normal
>> way, and the init script finds and loopback-mounts the ISO image and
>> booting continues as normal.
>
> Wow. I don't mean to offend, but this seems like an incredibly bad way
> of doing this. Isn't this really slow in the boot up because you must
> wait for the entire ISO to download? It also requires the client to
> have more than enough RAM to have the entire ISO in memory? It sounds
> like the entire memory used by the ISO remains unavailable to the booted
> system.
Well, it depends on your definition of "bad". For the purposes I
originally wrote it for, the ISO is going to be fairly small (~70MB or
less), and the target machines will have a lot of memory. So for that
situation, it works well enough, doesn't waste an appreciable amount of
memory, and fits into existing tools fairly easily.
Yep, the overhead in this context is utterly irrelevant. We're talking about
scenario where the host will be running all its storage over iSCSI with Gig-E
so 70 MB is nothing at all. The host will also be running multiple guest
VMs with multi-GB of of RAM allocated to guests, to 70 MB in memory is again
nothing at all. And 70 MB host image size is before we've even got serious
about stripping down to minimal size. The simplicity of pulling down the ISO
in the initial TFTP request easily wins here.
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 -=|
9:29 p.m.
Warren Togami wrote:
http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7...
>
> The way it works is to bundle the complete ISO image inside the initrd.
> The kernel and (bloated) initrd are downloaded using PXE in the normal
> way, and the init script finds and loopback-mounts the ISO image and
> booting continues as normal.
Wow. I don't mean to offend, but this seems like an incredibly bad way
of doing this. Isn't this really slow in the boot up because you must
wait for the entire ISO to download? It also requires the client to
have more than enough RAM to have the entire ISO in memory? It sounds
like the entire memory used by the ISO remains unavailable to the booted
system.
I need something similar to boot read-only OS images over PXE boot for
LTSP. Upstream LTSP5 uses nbd to serve a raw squashfs image as a
network block device, which means only a tiny bit needs to be in the
initrd and very little memory overhead. Parts of the read-only image
are streamed over the network on demand.
One architecture I've outlined here in the past, but haven't gotten
around to implementing yet is-
mount the squashfs via nfs or fuse-httpfs or the like, then otherwise do
everything else the same. Then post-boot, allow the user if they wish
to migrate the used squashfs either to ram or local disk via the same
devicemapper mirror 'trick' I used for rebootless installation.
Then subsequently (or alternately) you can use my rebootless
installation technique to convert the LiveOS(network-style) type running
OS into a completely normal installed running OS, without even having to
reboot. bwahahaha...
I forget the persons name, but I remember someone had already done the
first part of that, who posted here and on anaconda-devel within the
last year.
-dmc
I'm waiting on Jeremy to get back regarding a long-term plan for
supporting mayflower-like things within mkinitrd itself. NBD support
was not accepted into mkinitrd because it would rely upon mayflower-like
functionality to do right.
Warren Togami
wtogami(a)redhat.com
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
10:12 p.m.
Douglas McClendon wrote:
Warren Togami wrote:
>
> I need something similar to boot read-only OS images over PXE boot for
> LTSP. Upstream LTSP5 uses nbd to serve a raw squashfs image as a
> network block device, which means only a tiny bit needs to be in the
> initrd and very little memory overhead. Parts of the read-only image
> are streamed over the network on demand.
One architecture I've outlined here in the past, but haven't gotten
around to implementing yet is-
mount the squashfs via nfs or fuse-httpfs or the like, then otherwise do
everything else the same. Then post-boot, allow the user if they wish
to migrate the used squashfs either to ram or local disk via the same
devicemapper mirror 'trick' I used for rebootless installation.
Then subsequently (or alternately) you can use my rebootless
installation technique to convert the LiveOS(network-style) type running
OS into a completely normal installed running OS, without even having to
reboot. bwahahaha...
I forget the persons name, but I remember someone had already done the
first part of that, who posted here and on anaconda-devel within the
last year.
Think that was me... I've hacked up anaconda's init to not exit, then
call run-init, if the right boot flag is set. Why hack anaconda's init?
Because all the network bits are there with a GUI to use to configure
the network for nfs or searching for an iso image/cd. Then, if you
don't want to type you could use a kickstart file/boot cmdline to set
the boot arguments. I'm looking to try a reboot-less install from within
anaconda. What I'm looking to do is to install a live(cd) image by
anaconda via nfs,hd,cd. Once that is in place, exit anaconda, run-init
on the newly cloned install, calling first-boot to configure and
customize the rest of the package selection. Does this sound
do-able/reasonable?
Jerry
3:21 a.m.
Warren Togami wrote:
http://git.fedoraproject.org/git/?p=livecd;a=commit;h=e0f0269d3a8f8f310e7...
>
> The way it works is to bundle the complete ISO image inside the initrd.
> The kernel and (bloated) initrd are downloaded using PXE in the normal
> way, and the init script finds and loopback-mounts the ISO image and
> booting continues as normal.
Wow. I don't mean to offend, but this seems like an incredibly bad way
of doing this. Isn't this really slow in the boot up because you must
wait for the entire ISO to download? It also requires the client to
have more than enough RAM to have the entire ISO in memory? It sounds
like the entire memory used by the ISO remains unavailable to the booted
system.
It fits our purpose:
- PXE boot will always happen over a fast LAN
- image size isn't too large (under 200 MB for P2V and
IIRC even less for ovirt)
- machines are known to have sufficient RAM
I need something similar to boot read-only OS images over PXE boot
for
LTSP. Upstream LTSP5 uses nbd to serve a raw squashfs image as a
network block device, which means only a tiny bit needs to be in the
initrd and very little memory overhead. Parts of the read-only image
are streamed over the network on demand.
The server side of this is much harder to set up.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
5910
days inactive
5910
days old
livecd@lists.fedoraproject.org
8 comments
6 participants
participants (6)
-
Chris Lalancette -
Daniel P. Berrange -
Douglas McClendon -
Jerry Vonau -
Richard W.M. Jones -
Warren Togami