Hi, i tested a Xen HVM-PV install (netinstall) and it seems that when it mkfs.ext4''ed the xvda1, it gave these IO errors... you can see that xen-blkfront was loaded. and i used LVM as backend. this is what happens... https://bugs.mageia.org/attachment.cgi?id=3695 it does mkfs.ext4 and then it tries to mount it... any ideas? Xen 4.2.1
Op donderdag 4 april 2013 22:06:12 schreef AL13N:> Hi, > > i tested a Xen HVM-PV install (netinstall) > > and it seems that when it mkfs.ext4''ed the xvda1, it gave these IO errors... > you can see that xen-blkfront was loaded. and i used LVM as backend. > > this is what happens... https://bugs.mageia.org/attachment.cgi?id=3695 > > it does mkfs.ext4 and then it tries to mount it... > > any ideas? > > Xen 4.2.1this is the qemu log output: (i don''t know if some parts are bad or not) -------------------------------- domid: 44 -videoram option does not work with cirrus vga device model. Videoram set to 4M. Using file /dev/vg-storage/testhvm2 in read-write mode Watching /local/domain/0/device-model/44/logdirty/cmd Watching /local/domain/0/device-model/44/command Watching /local/domain/44/cpu qemu_map_cache_init nr_buckets = 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid = aea38379-daf9-0196-8d92-e97d6af898c2 xen be core: xen be core: can''t open gnttab device can''t open gnttab device populating video RAM at ff000000 mapping video RAM from ff000000 Register xen platform. Done register platform. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. xs_read(/local/domain/0/device-model/44/xen_extended_power_mgmt): read error xs_read(): vncpasswd get error. /vm/aea38379-daf9-0196-8d92- e97d6af898c2/vncpasswd. Log-dirty: no command yet. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 vcpu-set: watch node error. xs_read(/local/domain/44/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/44/log-throttling'' medium change watch on `/local/domain/44/log-throttling'' - unknown device, ignored cirrus vga map change while on lfb mode mapping vram to f0000000 - f0400000 platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state. Unknown PV product 3 loaded in guest PV driver build 1 region type 0 at [f3000000,f3020000). squash iomem [f3000000, f3020000). region type 1 at [c100,c140).
Op donderdag 4 april 2013 22:47:31 schreef AL13N: [...] I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 ... Unknown PV product 3 loaded in guest PV driver build 1 the io thing could refer to the disk... maybe the unknown pv stuff, are those number supposed to match? what do they refer to? is this something like the xen-blkfront driver?
Op zaterdag 6 april 2013 20:43:40 schreef AL13N:> Op donderdag 4 april 2013 22:47:31 schreef AL13N: > [...] > > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 > ... > Unknown PV product 3 loaded in guest > PV driver build 1 > > > the io thing could refer to the disk... maybe > > the unknown pv stuff, are those number supposed to match? what do they refer > to? > > is this something like the xen-blkfront driver?it appears this is really libvirt''s fault? when i create an lvm entry with virt-manager, it seems to create an lvm which is an active snapshot destination for a source (that doesn''t exist), which has a 4MB COW space... this runs out fairly quick and thus fucks up shit. I have no idea why the hell libvirt would do something like this... why in godsname would this be needed???
On Sat, Apr 06, 2013 at 11:17:15PM +0200, AL13N wrote:> Op zaterdag 6 april 2013 20:43:40 schreef AL13N: > > Op donderdag 4 april 2013 22:47:31 schreef AL13N: > > [...] > > > > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 > > ... > > Unknown PV product 3 loaded in guest > > PV driver build 1 > > > > > > the io thing could refer to the disk... maybe > > > > the unknown pv stuff, are those number supposed to match? what do they refer > > to? > > > > is this something like the xen-blkfront driver? > > > it appears this is really libvirt''s fault? > > when i create an lvm entry with virt-manager, it seems to create an lvm which > is an active snapshot destination for a source (that doesn''t exist), which has > a 4MB COW space... > > this runs out fairly quick and thus fucks up shit. > > I have no idea why the hell libvirt would do something like this... why in > godsname would this be needed???Perhaps the good folks at the libvirt mailing list might know. I would recommend you post your question there.> > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >