[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Qemu upstream bugs with xen



On Fri, 18 Jan 2013, Fabio Fantoni wrote:
> Il 18/01/2013 14:00, Stefano Stabellini ha scritto:
> > On Fri, 18 Jan 2013, Fabio Fantoni wrote:
> >> 1) Both linux and windows domU with qemu upstream have an additional
> >> empty floppy and cdrom.
> >> Is there a way to remove these additionals block devices?
> > the best way would be to pass a device or a global command line option
> > to QEMU to change the default for isa-fdc
> >
> >
> >> 2) xl cd-eject and cd-insert are not working:
> >>
> >> xl -vvv cd-eject W7 hdb
> >> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1b95990: create:
> >> how=(nil) callback=(nil) poller=0x1b95930
> >> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
> >> vdev=hdb spec.backend=phy
> >> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb,
> >> backend phy unsuitable as phys path not a block device
> >> libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no
> >> suitable backend for disk hdb
> > cd-eject should work by trying to insert an empty cdrom.
> > In particular the disk format should be LIBXL_DISK_FORMAT_EMPTY, but I
> > think this is not the case here.
> > I guess it is a bug in parse_disk_config.
> >
> >
> >> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1b95990: abort
> >> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1b95990: destroy
> >> xc: debug: hypercall buffer: total allocations:4 total releases:4
> >> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> >> xc: debug: hypercall buffer: cache current size:2
> >> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
> >>
> >> xl -vvv cd-insert W7 hdb raw:/mnt/vm/iso/QUANTAL.iso
> >> libxl: debug: libxl.c:2389:libxl_cdrom_insert: ao 0x1d07990: create:
> >> how=(nil) callback=(nil) poller=0x1d079f0
> >> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
> >> vdev=hdb spec.backend=phy
> >> libxl: error: libxl_device.c:243:libxl__device_disk_set_backend: Disk
> >> vdev=hdb failed to stat: raw:/mnt/vm/iso/QUANTAL.iso: No such file or
> >> directory
> > It looks like it is trying to stat "raw:/mnt/vm/iso/QUANTAL.iso" instead
> > of "/mnt/vm/iso/QUANTAL.iso".  The format parsing must be wrong.
> >
> >
> >> libxl: debug: libxl_event.c:1482:libxl__ao_abort: ao 0x1d07990: abort
> >> libxl: debug: libxl_event.c:1472:libxl__ao__destroy: ao 0x1d07990: destroy
> >> xc: debug: hypercall buffer: total allocations:4 total releases:4
> >> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> >> xc: debug: hypercall buffer: cache current size:2
> >> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
> >>
> >> Seem there is parsing error about backend and device/iso path, for now I
> >> not found solution for fix it on code.
> I've added -nodefaults option to qemu upstream to remove empty floppy 
> and cdrom with success. Please could this be added by default on libxl 
> on qemu upstream starting?

The problem with -nodefaults is that it changes a lot of other things
aside from the floppy drive:

default_serial = 0;
default_parallel = 0;
default_virtcon = 0;
default_monitor = 0;
default_vga = 0;
default_net = 0;
default_floppy = 0;
default_cdrom = 0;
default_sdcard = 0;

libxl should always set the right command line options for vga and
network, and most of the other settings don't matter for us.
However I am concerned about the monitor and the cdrom drive.

I thought that we always wanted to have a cdrom drive on HVM guests,
even if empty.

It would be better to find a way to change only the floppy default
setting.


> About cd-eject cd-insert parsing bug can you solve please?

Yes, however I am a bit busy at the moment so it might take some time.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.