Xen 4.0.0-rc5 with xen/stable 2.6.32.9 dom0 kernel, blktap2, relative mouse

Xen 4.0.0-rc5 with xen/stable 2.6.32.9 dom0 kernel, blktap2, relative mouse

[Pasi Kärkkäinen]

Hello,

I just tried running Xen 4.0.0-rc5 (64bit) with latest xen/stable 2.6.32.9 dom0 kernel (64bit aswell).
System boots up fine, and I'm able to run PV guests using phy: disk backend (lvm volumes).

I tried using tap:aio: file-based storage with virt-manager for a PV guest. 
It seems it doesn't really work, the guest waits for a long time 
initializing disk drivers/devices, and then complains about not having any disks.

$ xm list -l testfoo
..
    (device
        (tap
            (protocol x86_64-abi)
            (uuid f7723325-9ff4-96f7-0808-9ec05a00a4b8)
            (bootable 1)
            (dev xvda:disk)
            (uname tap:aio:/var/lib/libvirt/images/testfoo.img)
            (mode w)
            (backend 0)
            (VDI )
        )
    )

Am I supposed to have that 'uname' there? This could be a problem with virt-manager or libvirt,
so I'll try with plain normal /etc/xen/ cfgfiles next..

Also it seems pvfb uses the broken 'relative' mouse instead of 'absolute', 
any ideas why that happens? 

-- Pasi

Re: Xen 4.0.0-rc5 with xen/stable 2.6.32.9 dom0 kernel, blktap2, relative mouse

[Pasi Kärkkäinen]

On Thu, Mar 04, 2010 at 05:44:21PM +0200, Pasi Kärkkäinen wrote:
> Hello,
> 
> I just tried running Xen 4.0.0-rc5 (64bit) with latest xen/stable 2.6.32.9 dom0 kernel (64bit aswell).
> System boots up fine, and I'm able to run PV guests using phy: disk backend (lvm volumes).
> 
> I tried using tap:aio: file-based storage with virt-manager for a PV guest. 
> It seems it doesn't really work, the guest waits for a long time 
> initializing disk drivers/devices, and then complains about not having any disks.
> 
> $ xm list -l testfoo
> ..
>     (device
>         (tap
>             (protocol x86_64-abi)
>             (uuid f7723325-9ff4-96f7-0808-9ec05a00a4b8)
>             (bootable 1)
>             (dev xvda:disk)
>             (uname tap:aio:/var/lib/libvirt/images/testfoo.img)
>             (mode w)
>             (backend 0)
>             (VDI )
>         )
>     )
> 
> Am I supposed to have that 'uname' there? This could be a problem with virt-manager or libvirt,
> so I'll try with plain normal /etc/xen/ cfgfiles next..
> 

Hmm, it seems phy: based guest has that 'uname' aswell:

    (device
        (vbd
            (protocol x86_64-abi)
            (uuid b7c115d7-138a-5cd0-a179-3038ba49d349)
            (bootable 1)
            (devid 51712)
            (driver paravirtualised)
            (dev xvda:disk)
            (uname phy:/dev/vg_f12test/f12test)
            (mode w)
            (backend 0)
        )
    )

So I guess that's all fine.

What's the best way to troubleshoot the blktap2 problem?

I have 'blktap' module loaded in dom0, and xen 4.0.0-rc5 
should have the required blktap2 tools..

-- Pasi

> Also it seems pvfb uses the broken 'relative' mouse instead of 'absolute', 
> any ideas why that happens? 
> 
> -- Pasi
> 

Re: Xen 4.0.0-rc5 with xen/stable 2.6.32.9 dom0 kernel, blktap2, relative mouse

[Jeremy Fitzhardinge]

On 03/04/2010 07:51 AM, Pasi Kärkkäinen wrote:
> On Thu, Mar 04, 2010 at 05:44:21PM +0200, Pasi Kärkkäinen wrote:
>    
>> Hello,
>>
>> I just tried running Xen 4.0.0-rc5 (64bit) with latest xen/stable 2.6.32.9 dom0 kernel (64bit aswell).
>> System boots up fine, and I'm able to run PV guests using phy: disk backend (lvm volumes).
>>
>> I tried using tap:aio: file-based storage with virt-manager for a PV guest.
>> It seems it doesn't really work, the guest waits for a long time
>> initializing disk drivers/devices, and then complains about not having any disks.
>>
>> $ xm list -l testfoo
>> ..
>>      (device
>>          (tap
>>              (protocol x86_64-abi)
>>              (uuid f7723325-9ff4-96f7-0808-9ec05a00a4b8)
>>              (bootable 1)
>>              (dev xvda:disk)
>>              (uname tap:aio:/var/lib/libvirt/images/testfoo.img)
>>              (mode w)
>>              (backend 0)
>>              (VDI )
>>          )
>>      )
>>
>> Am I supposed to have that 'uname' there? This could be a problem with virt-manager or libvirt,
>> so I'll try with plain normal /etc/xen/ cfgfiles next..
>>
>>      
> Hmm, it seems phy: based guest has that 'uname' aswell:
>
>      (device
>          (vbd
>              (protocol x86_64-abi)
>              (uuid b7c115d7-138a-5cd0-a179-3038ba49d349)
>              (bootable 1)
>              (devid 51712)
>              (driver paravirtualised)
>              (dev xvda:disk)
>              (uname phy:/dev/vg_f12test/f12test)
>              (mode w)
>              (backend 0)
>          )
>      )
>
> So I guess that's all fine.
>
> What's the best way to troubleshoot the blktap2 problem?
>
> I have 'blktap' module loaded in dom0, and xen 4.0.0-rc5
> should have the required blktap2 tools..
>    

I haven't had any problems with blktap2 at all lately, using the xend/xm 
toolstack.  Are there any messages in the various logfiles and/or kernel 
which might indicate a problem?

     J

Re: Xen 4.0.0-rc5 with xen/stable 2.6.32.9 dom0 kernel, blktap2, relative mouse

[Jeremy Fitzhardinge]

On 03/04/2010 07:44 AM, Pasi Kärkkäinen wrote:
> Also it seems pvfb uses the broken 'relative' mouse instead of 'absolute',
> any ideas why that happens?
>    

I've noticed that too.  I poked around a little to try and work out what 
was going on, but I got stuck.  "xinput" is showing the pointer device 
is "absolute" in the domain, which looks OK - but it is still getting 
relative motion.

Are you using vnc?

     J

Re: Xen 4.0.0-rc5 with xen/stable 2.6.32.9 dom0 kernel, blktap2, relative mouse

[Pasi Kärkkäinen]

On Thu, Mar 04, 2010 at 10:24:07AM -0800, Jeremy Fitzhardinge wrote:
> On 03/04/2010 07:44 AM, Pasi Kärkkäinen wrote:
>> Also it seems pvfb uses the broken 'relative' mouse instead of 'absolute',
>> any ideas why that happens?
>>    
>
> I've noticed that too.  I poked around a little to try and work out what  
> was going on, but I got stuck.  "xinput" is showing the pointer device  
> is "absolute" in the domain, which looks OK - but it is still getting  
> relative motion.
>
> Are you using vnc?
>

I was using virt-manager, which uses virt-viewer I believe..
which is vnc based, so yes..

-- Pasi