Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: A bunch of questions about getting a working NetBSD/xen system



Louis Guillaume <louis%zabrico.com@localhost> writes:

smb answered, and I'll throw in my $0.02, at the risk of being a bit
redundant.


> 0. The goal: To have a NetBSD/xen dom0 machine on which to host guest
>    machines. Ideally this should:
>
>      o run on netbsd-x-stable whatever that is at the time.
>      o run unmodified oses; i.e. HVM support.

Certainly sensible if the OS you want to run in a domU does not support

>    It does not appear that my BIOS supports this though. If I use
>    "cpuctl identify" I do not see the "VT" instruction listed, and
>    nowhere in my dmesg output do I have an indication that it's
>    turned off in the Bios as some sources (NetBSD wiki's xen page)
>    suggest.

Look at 'xen dmesg'.  I have a box running xen 3.1.4 with an amd64
XEN3_DOM0 kernel, and it has both amd64 XEN3_DOMU and i386 XEN3PAE_DOMU
(or whatever it's called) guests.  My dmesg shows:

(XEN) System RAM: 2020MB (2069292kB)
(XEN) Xen heap: 14MB (15156kB)
(XEN) Domain heap initialised: DMA width 32 bits
(XEN) Processor #0 6:15 APIC version 20
(XEN) Processor #1 6:15 APIC version 20
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2999.745 MHz processor.
(XEN) VMX disabled by Feature Control MSR.
(XEN) CPU0: Intel(R) Core(TM)2 Duo CPU     E6850  @ 3.00GHz stepping 0b
(XEN) Booting processor 1/1 eip 90000
(XEN) VMX disabled by Feature Control MSR.
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     E6850  @ 3.00GHz stepping 0b
(XEN) Total of 2 processors activated.

and I think this is a VMX-capable machine.

>    Can I use netbsd-5 instead of -current for DOM0/PAE yet?

in production here, no issues - with PV mode.

> 3. I have DOM0 working with -current. But it seems awfully slow! Disk
>    I/O and also net I/O seem to be much slower than normal. Is there
>    anything that needs to be done to have reasonable performance in
>    DOM0. Will the DOMU's be able to perform well despite the slowness
>    in DOM0?

That sounds messed up.  I have not observed dom0 to be noticeably slower
than running on bare metal w/o xen.

For domU disks, I make files in the dom0 filesystem, and vnconfig them.
I found that dd from a file is ~90% of the speed of the disk, and dd
From the 'raw disk' in the domU is again 90% of that, or something more
or less like that.  Basically there was a noticeable hit but not a big
deal.

> 4. Is it "bad" practice to use the DOM0 for anything other than
>    serving the guest oses? For example - bad idea to build.sh the
>    system in DOM0 or compile pkgsrc packages?

It depends on your stability/security concerns and what you want to
achieve.  Standard religion is to do nothing in dom0 but support domUs,
both for security and somewhat for stability.  But if it's more
important to use it to build than the extra isolation.  go right ahead.

> 5. If I'm able to get an HVM setup going, will NetBSD run unmodified
>    as a guest?

I think so; that's kind of the definition of HVM.

> 6. What's the deal with SMP on xen? I see the following in dmesg:

xen kernel supports SMP.  netbsd dom0 and domU both only handle 1 cpu.
So as smb said, you get sharing across domUs, but no one domU (or dom0)
can get multiple CPUs.

In my world, this has been ok, except for some servers that run
svn/trac.  trac is so piggy of cpu time becaues of all the interpreted
python that having an 8-cpu machine really helps.  But for sane
workloads and lots of domUs, the current situation is ok for me.


Attachment: pgp0TREdfdR3j.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index