Hi,
I also had a problem with the install time with ldoms guest clients
on a Glendale blade. But it
got much better once I started testing with b110.
7074: Sun4v LDoms Virtual Guest takes 30 minutes to install miniroot -
CLOSED
closed since it now only takes 8 minutes which is still much longer than a
non-ldom machine.
thanks
Jerry
On 04/13/09 09:23 AM, Sarah Jelinek wrote:
> Hi Mike,
>
> Thank you for taking the time to use AI and to provide such detailed
> feedback. We appreciate it! My comments/questions inline...
>> Very quick summary:
>>
>> - I was successful at installing build 111 using AI.
>> - It was hard, partially because of so many new and new-to-me parts
>> - I had no viable x86 box on the right network segment to run the
>> install server
>> - Proxy support needs to improve at multiple places
>>
>> This message is intended to help others that may be trying to do the
>> same. There are some rough edges that I point out that I assume are
>> known issues but I haven't searched them all out in bugzilla yet.
>>
>>
>> More details...
>>
>> I started out trying to figure out how to cope with the lack of a
>> system that can do AI in the lab where my sun4v box is at. I figured
>> this couldn't be too hard. I just needed an ipkg branded zone on a
>> different LDom. Talk about Chickens and eggs. I'll work up a blog
>> post to describe how I did this. The high level of what I did on a
>> SXCE 108 install is:
>>
>> 1. Get pkg-gate from mercurial
>> 2. Build pkg
>> 3. Install pkg packages
>> 4. Fake global zone's notion of entire
>> 5. Create the zone
>> 6. Install the zone
>> 7. Configure the zone
>> 8. Install installadm, mkisofs
>> 9. Mount iso in zone
>> 11. Create install service
>> 12. Configure DHCP
>>
>> Hmmm... looks like the 12 step program to end my addition to SXCE.
>>
>> It seems really strange that I need DHCP to use wanboot. I tried with
>> just wanboot but the install failed very early on.
>>
>
>> Wanboot is slow. Really slow. I'm not sure of the exact time, but
>> downloading the 167 MB boot_archive took ~40 minutes. In tests that I
>> did last week, I was able to push over 900 Mbit/sec between the same
>> two boxes. If wanboot cannot be improved due to problems with
>> openboot or similar, the boot_archive needs to be stripped down to the
>> point that it knows about network drivers and whatever is needed to
>> load the image into a ramdisk.
>>
> Really? I have been testing sparc the last week and it only took on
> the order of 5 minutes or so to download the boot archive with
> wanboot. When you were able to push the 900Mbit/sec speed in testing,
> what were the differences, other than wanboot delivering the data? Are
> others attached and using the same network?
>
> I would like a bit more information on the network during the wanboot
> process. Normal network trouble shooting data, like bandwidth, dropped
> packets, retries... As I said, I did not see the times you are
> describing.
>> I started out with an LDom with 700 MB of memory. That failed with an
>> error message that made a lot of sense to me, but my guess is that the
>> typical person may be confused. I lost the exact message.
>>
>> After the first failure, I added 1 GB of RAM. This time it errored
>> out when pkg couldn't find pkg.opensolaris.org. Because vi is not in
>> the miniroot (sigh) and my svccfg-foo is lacking, I worked around this
>> with something like:
>>
> well.. file enhancement requests for inclusion of these if you want.
> However, in trying to keep the microroot small choices have to be made
> about what we must include.
>> # cd /lib/svc/method
>> # mv auto-installer auto-installer.orig
>> # cat > auto-installer
>> #! /bin/sh
>>
>> http_proxy=...
>> export http_proxy
>> /lib/svc/method/auto-installer.orig "$@"
>> ^D
>> # svcadm clear auto-install
>>
>> This got the installation going. Then I ran into bug 6804.
>>
>> http://defect.opensolaris.org/bz/show_bug.cgi?id=6804
>>
>> I added 300 MB of memory (now at 2024 MB) and tried again. With the
>> aforementioned http_proxy workaround applied again, the installation
>> completed without problems. Hooray!
>>
>>
>> Along the way I also had troubles due to...
>>
>> - When the install server is rebooted, it doesn't start serving
>> whatever it was serving before. Each time I needed to run
>> "installadm start sparc-preview"
>>
> I believe this will be fixed with the putback for 7218 which was
> integrated on 4/6. Not sure if the bits you installed had this changeset.
>> - installadm doesn't cause an apache instance to start to serve
>> wanboot.cgi. As such, after rebooting the zone I needed to run
>>
>> /usr/apache2/2.2/bin/httpd \
>> -f /var/installadm/ai-webserver/ai-httpd.conf
>>
>>
>>
> Hmm.. this should work I believe as a result of the putback for 4488.
> Let me take a look at the changes that went in for this bug and get
> back to you.
>> Key areas of improvement that would help a lot are:
>>
>> - Add a global and/or per-mirror proxy server to pkg. That is, when
>> accessing pkg.opensolaris.org I need to use a proxy, but if I have
>> another repository inside my company, I should probably access that
>> directly.
>> - Enhance AI to deal with proxy servers reasonably.
>> - Make the pkg.opensolaris.org repository mirror-able using something
>> other than rsync. Output from "zfs send" and "zfs send -I" over
>> http or https would be great.
>>
>>
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
--
Jerry Edwards Sun Microsystems Inc.
Manager, Network and Platform QA 12 Network Circle
Phone: (650) 786-4632 M/S MPK12-126
Fax: (650) 786-2841 Menlo Park, CA 94025
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090413/59a312e2/attachment.html>
