Re: Xen/Xentools 3.3 Domain-Unnamed

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

On Friday 15 August 2008 12:00:51 bsd-xen%roguewrt.org@localhost wrote:
> Christoph Egger wrote:
> > On Friday 15 August 2008 08:55:55 Sarton O'Brien wrote:
> >> I've been testing the newer xen packages and have had a few problems.
> >>
> >> The packages themselves do not seem to care if an older xenkernel or
> >> xentools is installed and will overwrite the existing packages. No big
> >> deal but also not ideal :)
> >
> > hmm... I thought, the CONFLICT settings in the package' Makefile handles
> > this.
>
> Makes for some amusing errors :)

Well, this is my first package.

> >> When shutting down or rebooting a domu I'm left with:
> >>
> >> Domain-Unnamed                               1   467     1     ---s--
> >> 46.0
> >>
> >> In 'xm list' ... but not in 'xm top' (it displays for little while in
> >> 'xm top' then disappears). If rebooting, the domu will not start up by
> >> itself.
> >>
> >> I can't kill it and when doing multiple domu reboots, only one ever
> >> exists.
> >
> > Everytime I try to destroy it, I see it freed some memory. So repeating
> > xm destroy<domain>  ; xm list  kills it finally.
> >
> > There's something asynchronous within the hypervisor which obviously
> > needs to be debugged.
> >
> > This happens for both PV and HVM guests.

The guest get completely destroyed when the guest memory has been unmapped.
As long as Xen or Dom0 has any guest page mapped, the guest won't get 
completely destroyed.

> >> It does seem to occupy memory ... but an odd amount. It seems to release
> >> some but not all ... well, it seems to release it slowly. After two
> >> reboots of a domu I have to wait a bit before an new instance will
> >> launch.
> >
> > You can shorten the wait by repeating xm destroy<domain>  ; xm list
> >
> >> I also had a console problem but I'll leave that for when I see it
> >> again.
> >
> > Is this that you had no console output from a PV guest having the
> > domain id   "1" ?  I have tracked this down to be a off-by-one bug either
> > in xenconsole, xenconsoled or in the kernels xenconsole driver.
> >
> >> uname -a
> >> NetBSD gogeta.internal 4.99.72 NetBSD 4.99.72 (XEN3_DOM0) #0: Mon Aug 11
> >> 23:57:46 EST 2008
> >> root%spike.internal@localhost:/usr/obj/sys/arch/amd64/compile/XEN3_DOM0  
> >> amd64
> >>
> >> # pkg_info |grep xen
> >> xenkernel33-3.3-18261 Xen3.3.0-rc3 Kernel
> >> xentools33-3.3-18261 Userland Tools for Xen 3.3.x
> >>
> >> Sarton
>
> Thanks for the info. It seems you're on to all the problems I've had
> thus far.
>
> Other than the above, everything seems to run fine. Do _you_ know of any
> other issues? Specifically ones that won't be resolved quickly or
> anything stability related? I can live with what I've encountered so far
> so I won't revert just yet, if that's the general extent of it.

Well, I know of some hypervisor bugs which have been fixed upstream.
These let some HVM guests in certain conditions crash the hypervisor.

Since Xen 3.2, the guest entry

    disk = [ 'file:/path/to/guest.img,0x1,w' ]

only and only works on plain guest image formats.
Other image formats (qcow, vmdk, etc.) no longer works that way due to
a security issue - which won't be fixed in Xen 3.1.4.

In order to make this work, two things must be done:

1. Change the guest entry to

     disk = [ 'tap:aio:/path/to/guest.img,0x1,w' ]

2. Go into pkgsrc/sysutils/xentools33/files/ and implement the stub functions
    in blk_netbsd.c and blktapctrl_netbsd.c in order to make blktapctrl
    working.

3. Good luck :)


You can start trying out some Xen 3.2/3.3 features which are useable w/o
any work on NetBSD Dom0/DomU:

- ACPI S3 support for HVM guests
- PowerNow for Barcelona/Phenom
- HAP (Hardware Assisted nested Paging) for HVM guests for Barcelona/Phenom


I can happily run 4 guests with a good amount of memory:

dom0# xm list 
Name                                        ID   Mem VCPUs      State   
Time(s)
Domain-0                                     0   512     1     r-----   5206.3
HVM64-NetBSD                                 3  1024     4     -b----    367.9
HVM64-Slackware                              7   128     1     ------     29.4
SLES-9.3_Textmode                            1  1024     1     ------    379.6
memtest                                      6  1000     1     r-----    969.7


Christoph