From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Coleman Subject: Re: Stub domains broken in 3.4.0-rc3? Date: Fri, 8 May 2009 17:35:23 -0400 Message-ID: <5411dbdc0905081435s47c8c8dg136beae8dc2d5da7@mail.gmail.com> References: <5411dbdc0905041256w1d57cd5fvfa62d1574384851f@mail.gmail.com> <4A043FBF.6090105@eu.citrix.com> <5411dbdc0905080928m58ca21c3jab7992114dc55f85@mail.gmail.com> <4A047D89.60002@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4A047D89.60002@eu.citrix.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: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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, but > 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. > > Keith Coleman wrote: > >> >> 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. >> >> # 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' >> >> >> # 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". >> >> # 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 'ai= o') >> 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.iso >> >> >> >> -Keith >> > > > 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. 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. I would very much like to see stub domains working properly in time for the 3.4.0 release! Keith