Hi,
I''m running snv84 on a SunFire x2200M2, 2 dualcore opterons, 8GB ram, 2
mirror sata disks (zfs).
I tried to install both Ubuntu 7.1 Desktop and Fedora 8 into a HVM domU but
failed everytime.
The VNC-Server for the domU dies, but the domain still consumes CPU time, disks
go idle after a while (zpool iostat or iostat show zero I/O). The domUs booted
up fine, the installer started, partitioned and formated the virtual disks
(zvols) and started copying the stuff over. Write access to the virtual disks
seemed veeery slow (less than 1MB/s, the domU was in blocked state huge amounts
of time). The hosts syslog didn''t have anything abnormal.
Here''s what I tried and the output:
markgraf.bti1 ~ # virt-install --hvm --name=hvmlx --ram=1024
--file=/dev/zvol/dsk/data/zones/hvmlx --vnc \
--cdrom=/data/77/ubuntu-7.10-desktop.iso
Starting install...
Creating domain... 0 B 00:01
VNC Viewer Free Edition 4.1.2 for X - built Feb 12 2008 00:59:52
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
Wed Mar 19 23:31:42 2008
CConn: connected to host 127.0.0.1 port 5900
CConnection: Server supports RFB protocol version 3.3
CConnection: Using RFB protocol version 3.3
Wed Mar 19 23:32:24 2008
TXImage: Using default colormap and visual, TrueColor, depth 24.
CConn: Using pixel format depth 6 (8bpp) rgb222
CConn: Using ZRLE encoding
Wed Mar 19 23:32:25 2008
CConn: Throughput 20128 kbit/s - changing to hextile encoding
CConn: Throughput 20128 kbit/s - changing to full colour
CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
CConn: Using hextile encoding
Wed Mar 19 23:43:26 2008
CConn: Throughput 20000 kbit/s - changing to raw encoding
CConn: Using raw encoding
Thu Mar 20 02:08:45 2008
main: End of stream
libvir: error : invalid argument in __virGetDomain
libvir: Xen Store error : out of memory
Traceback (most recent call last):
File "/usr/bin/virt-install", line 657, in ?
main()
File "/usr/bin/virt-install", line 606, in main
dom = guest.start_install(conscb,progresscb)
File
"/export/builds/xvm_84/proto/install/usr/lib/python2.4/site-packages/virtinst/Guest.py",
line 638
, in start_install
File
"/export/builds/xvm_84/proto/install/usr/lib/python2.4/site-packages/virtinst/Guest.py",
line 701
, in _do_install
File "/usr/lib/python2.4/vendor-packages/libvirt.py", line 555, in
lookupByName
if ret is None:raise libvirtError(''virDomainLookupByName()
failed'', conn=self)
libvirt.libvirtError: virDomainLookupByName() failed out of memory
The same happens when trying to install Fedora.
xm top also fails:
markgraf.bti1 ~ # xm top
Failed to retrieve statistics from libxenstat
any hints on how to get this going? Did I miss something or tried something
really stupid? ;-)
Cheers,
Bernd
This message posted from opensolaris.org
ZFS and dom0 ballooning don''t get on well together. You can mitigate this by limiting the amount of memory that dom0 will use with a ''dom0_mem=4G'' (say) argument to xen.gz in /boot/grub/menu.lst. dme.
I tried xm mem-set dom0 to 4GB before with the same effect. I''ll give the kernel arg a go then... thanks, bernd This message posted from opensolaris.org
and again the installation died. dom0_mem=2048M was set (and booted ;-)) same error as before on the ubuntu install. I''ll go and try Fedora again. This message posted from opensolaris.org
Bernd Markgraf wrote:> Hi, > > I''m running snv84 on a SunFire x2200M2, 2 dualcore opterons, 8GB ram, 2 mirror sata disks (zfs). > I tried to install both Ubuntu 7.1 Desktop and Fedora 8 into a HVM domU but failed everytime. > The VNC-Server for the domU dies, but the domain still consumes CPU time, disks go idle after a while (zpool iostat or iostat show zero I/O). The domUs booted up fine, the installer started, partitioned and formated the virtual disks (zvols) and started copying the stuff over. Write access to the virtual disks seemed veeery slow (less than 1MB/s, the domU was in blocked state huge amounts of time). The hosts syslog didn''t have anything abnormal. > > Here''s what I tried and the output: > > markgraf.bti1 ~ # virt-install --hvm --name=hvmlx --ram=1024 --file=/dev/zvol/dsk/data/zones/hvmlx --vnc \ --cdrom=/data/77/ubuntu-7.10-desktop.iso > > > Starting install... > Creating domain... 0 B 00:01 > > VNC Viewer Free Edition 4.1.2 for X - built Feb 12 2008 00:59:52 > Copyright (C) 2002-2005 RealVNC Ltd. > See http://www.realvnc.com for information on VNC. > > Wed Mar 19 23:31:42 2008 > CConn: connected to host 127.0.0.1 port 5900 > CConnection: Server supports RFB protocol version 3.3 > CConnection: Using RFB protocol version 3.3 > > Wed Mar 19 23:32:24 2008 > TXImage: Using default colormap and visual, TrueColor, depth 24. > CConn: Using pixel format depth 6 (8bpp) rgb222 > CConn: Using ZRLE encoding > > Wed Mar 19 23:32:25 2008 > CConn: Throughput 20128 kbit/s - changing to hextile encoding > CConn: Throughput 20128 kbit/s - changing to full colour > > CConn: Using pixel format depth 24 (32bpp) little-endian rgb888 > CConn: Using hextile encoding > > Wed Mar 19 23:43:26 2008 > CConn: Throughput 20000 kbit/s - changing to raw encoding > CConn: Using raw encoding > > Thu Mar 20 02:08:45 2008 > main: End of stream > libvir: error : invalid argument in __virGetDomain > libvir: Xen Store error : out of memory > Traceback (most recent call last): > File "/usr/bin/virt-install", line 657, in ? > main() > File "/usr/bin/virt-install", line 606, in main > dom = guest.start_install(conscb,progresscb) > File "/export/builds/xvm_84/proto/install/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 638 > , in start_install > File "/export/builds/xvm_84/proto/install/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 701 > , in _do_install > File "/usr/lib/python2.4/vendor-packages/libvirt.py", line 555, in lookupByName > if ret is None:raise libvirtError(''virDomainLookupByName() failed'', conn=self) > libvirt.libvirtError: virDomainLookupByName() failed out of memory > > The same happens when trying to install Fedora. > > xm top also fails: > markgraf.bti1 ~ # xm top > Failed to retrieve statistics from libxenstat > > any hints on how to get this going? Did I miss something or tried something really stupid? ;-) > > Cheers, > Bernd > > > This message posted from opensolaris.org > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org >Sorry to ask, but what arch is OpenSolaris running as (32-bit or 64-bit, it choses automatically based on cpu checks) You need B85 afaik to correctly use domU guests with different architecture. Try booting x86-64 versions of both distros before anything. James
James wrote:> Bernd Markgraf wrote: > > Here''s what I tried and the output: > > > > markgraf.bti1 ~ # virt-install --hvm ... > Sorry to ask, but what arch is OpenSolaris running as (32-bit or 64-bit, > it choses automatically based on cpu checks) > > You need B85 afaik to correctly use domU guests with different > architecture. Try booting x86-64 versions of both > distros before anything.It seems that Bernd is trying to setup a HVM domU, and pre-b85 should allow 32-bit HVM domU even on 64-bit dom0. This message posted from opensolaris.org
James, as Juergen guessed right I''m trying to install a 32bit guest in a HVM domU on a 64bit host. All docs I found so far are pointing out this should work. The Fedora install still runs this time (started like roughly 6hours ago). As I said in the first post disk io really seems very slow (zpool iostat reporting a constant rate of ~300k/s, though the solaris host writes well above 20M/s to the same pool) here. If the install finishes this time thats the next point to investigate... This message posted from opensolaris.org
ok, failed again... but this time it wasn''t xenstored complaining. Mar 21 23:25:25 bti1 nv_sata: [ID 517869 kern.warning] WARNING: nv_sata inst 0 port 1: excessive interrupt processing. Disabling port int_status=1 clear=0 which kindly stopped all io to the zpool. so for the next test I''ll try to either split up the zfs mirror or use a file on an ufs slice... This message posted from opensolaris.org
> ok, failed again... > but this time it wasn''t xenstored complaining. > > Mar 21 23:25:25 bti1 nv_sata: [ID 517869 > kern.warning] WARNING: nv_sata inst 0 port 1: > excessive interrupt processing. Disabling port > int_status=1 clear=0 > > which kindly stopped all io to the zpool. so for the > next test I''ll try to either split up the zfs mirror > or use a file on an ufs slice...This seems to be a generic nv_sata driver problem, and probably is unrelated to xvm/xen. I got the same problem on metal a few times, and filed bug 6642154 "nv_sata: excessive interrupt processing": http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6642154 Problem is that nv_sata''s interrupt handler submits the next command to the controller when it detects that the previous command has completed, and before returning from the nv_sata interrupt handler it checks if there is another interrupt pending in the controller. I case the disk is fast and the interrupt processing in the kernel is slow the next command has already completed before nv_sata checks for another pending interrupt, so it loops around in the interrupt handler and repeats the whole process. After ten loops in the interrupt handler the hardware is declared as defective with the message "excessive interrupt processing. Disabling port..." As a workaround I''m using a slightly modified nv_sata module which allows 32 loops instead of 10; there have been no more OS hangs with message "nv_sata: ... excessive interrupt processing" so far. diff --git a/usr/src/uts/common/sys/sata/adapters/nv_sata/nv_sata.h /usr/src/uts/common/sys/sata/adapters/nv_sata/nv_sata.h --- a/usr/src/uts/common/sys/sata/adapters/nv_sata/nv_sata.h +++ b/usr/src/uts/common/sys/sata/adapters/nv_sata/nv_sata.h @@ -625,7 +625,7 @@ typedef struct prde { * processing loop, declare the interrupt wedged and * disable. */ -#define NV_MAX_INTR_LOOP 10 +#define NV_MAX_INTR_LOOP 32 /* * flag values for nv_copy_regs_out This message posted from opensolaris.org
yes this seems to be the same problem. your fix corrected this misbehaviour. thanks for that! I/O performance still is way too low though. The Fedora install taking about 9hours. Writing with something like 300-500kB/s (no real measurement, just watching iostat and zpool iostat) when using a zvol (file image on ufs is about 2-3MB/s writing) with the domU being in blocked state for huge amounts of time when writing to the virtual disks. anyway the domU is running now... so I''ll play around with it and see how far I get. cheers, Bernd This message posted from opensolaris.org