From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: Stub domains broken in 3.4.0-rc3? Date: Sat, 09 May 2009 08:57:40 +0100 Message-ID: References: <6b7f6eb0905081641o11191e6l38baf3ce356ae9a7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <6b7f6eb0905081641o11191e6l38baf3ce356ae9a7@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Thiago Camargo Martins Cordeiro , Keith Coleman Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org Realistically at this point you're looking at 3.4.1 imo. Since 3.4.0 is out the door next week. -- Keir On 09/05/2009 00:41, "Thiago Camargo Martins Cordeiro" wrote: >> I would very much like to see stub domains working properly in time for = the >> 3.4.0 release! >=20 > +1 >=20 > :-D >=20 > 2009/5/8 Keith Coleman >> On Fri, May 8, 2009 at 2:44 PM, Stefano Stabellini >> wrote: >>> The problem seems to be the "phy" disk that does not work correctly, bu= t >>> I don't think it is caused by a bug in the new stubdomain config file >>> generator. >>> In fact I can reproduce the bug even using the old stubdom-dm script. >>>=20 >>> Keith Coleman wrote: >>>=20 >>>>=20 >>>> My current config file is just a slightly modified version of the >>>> xmexample.hvm. It works for regular HVM mode if I switch the >>>> stubdom-dm for qemu-dm. I have fs-backend running in the background. >>>>=20 >>>> # cat stub1-clean >>>> import os, re >>>> arch =3D os.uname()[4] >>>> if re.search('64', arch): >>>> =A0 =A0 arch_libdir =3D 'lib64' >>>> else: >>>> =A0 =A0 arch_libdir =3D 'lib' >>>> kernel =3D "/usr/lib/xen/boot/hvmloader" >>>> builder=3D'hvm' >>>> memory =3D 512 >>>> name =3D "stub1" >>>> vif =3D [ 'type=3Dioemu, bridge=3Deth0' ] >>>> disk =3D [ 'phy:/dev/testvg/stub1,hda,w', >>>> =A0 =A0 =A0 =A0 =A0'file:/root/isos/win2003entR2.iso,hdc:cdrom,r' ] >>>> device_model =3D '/usr/' + arch_libdir + '/xen/bin/stubdom-dm' >>>> #device_model =3D '/usr/' + arch_libdir + '/xen/bin/qemu-dm' >>>> boot=3D"dca" >>>> sdl=3D0 >>>> opengl=3D1 >>>> vnc=3D1 >>>> vnclisten=3D"0.0.0.0" >>>> vncpasswd=3D'' >>>> stdvga=3D0 >>>> serial=3D'pty' >>>> usb=3D1 >>>> usbdevice=3D'tablet' >>>>=20 >>>>=20 >>>> # cat /var/log/xen/qemu-dm-stub1.log >>>> Error: Device 768 (vbd) could not be connected. >>>> Device /dev/mapper/testvg-stub1 is mounted in a guest domain, >>>> and so cannot be mounted now. >>>> Using config file "/etc/xen/stubdoms/stub1-dm". >>>> Using config file "/etc/xen/stubdoms/stub1-dm". >>>>=20 >>>> # cat /var/log/xen/qemu-dm-stub1-dm.log >>>> domid: 71 >>>> Warning: vlan 0 is not connected to host network >>>> Strip off blktap sub-type prefix to /root/isos/win2003entR2.iso (drv '= aio') >>>> Watching /local/domain/0/device-model/71/logdirty/next-active >>>> Watching /local/domain/0/device-model/71/command >>>> char device redirected to /dev/pts/3 >>>> /root/xen-3.4-rc3/xen-unstable.hg/tools/ioemu-dir/hw/xen_blktap.c:628: >>>> Init blktap pipes >>>> xs_read(): vncpasswd get error. >>>> /vm/e0dd1e52-a827-8c47-7e3d-cc26941e4419/vncpasswd. >>>> medium change watch on `hdc' (index: 1): aio:/root/isos/win2003entR2.i= so >>>>=20 >>>>=20 >>>>=20 >>>> -Keith >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> I agree that this may have nothing to do with the new stubdom config >> generator. I have not been able to use stub domains in any of the >> 3.4.0-rc releases. >>=20 >> You are probably correct about an issue with the phy disk in stubdom. >> Even on the stable code (3.3.1) certain types of block devices don't >> seem to fully work in stub domains. DRBD is one such device. >>=20 >> I would very much like to see stub domains working properly in time >> for the 3.4.0 release! >>=20 >> Keith >>=20 >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >=20 >=20