On Mon, Feb 24, 2014 at 09:21:38PM +0100, Peter Lieven wrote: > Am 24.02.2014 13:54, schrieb Stefan Hajnoczi: > > On Sun, Jan 05, 2014 at 06:21:50PM +0100, Peter Lieven wrote: > >> In order to proceed with the integration of the NFS protocol driver into > >> qemu I was asked by Stefan to add integration for NFS into the > >> qemu-iotests. > >> > >> Unfortunately, this became more complex than I had expected because most > >> of the tests for non RAW formats only work with the file protocol because > >> they use shell commands like cp, rm or mv which obviously don't work > >> on nfs:// URLs. > >> > >> This series first changes all those tests that are not working out of the > >> box to support only the file protocol. > >> > >> After the NFS protocol is introduced in Patch 2 I fix most of them > >> to work with any protocol. > >> > >> After this series the qemu-iotests for NFS run through gracefully with > >> the RAW, QCOW2 and VMDK formats. > >> > >> There are 3 topics open: > >> - test 051 fails regardless which protocol is used (I already send a msg > >> to the list) > >> - test 052 should work, but it seems there is a bug in the bdrv_open > >> logic if the BDRV_O_SNAPSHOT flag is set and the protocol is anything > >> else than file. Maybe someone with more understanding of the whole > >> open logic could look at this. I do not believe that its sth which > >> has to do with the NFS driver since the test fails while opening the > >> backing file and other backing file tests run without problems. > >> - other protocols like sheepdog or ssh that are allowed to use other > >> formats > >> than raw should be tested. they actually can't never have run > >> qemu-iotests > >> with qcow2 protocol for instance. > >> > >> If you want to do your tests please make sure to have > >> [PATCHv5] block: add native support for NFS > >> [PATCH v2] vmdk: Allow vmdk_create to work with protocol > > Going through my email backlog. What is the status of this series? > The NFS driver and bare qemu-iotests support is merged. All the patches > that try to fix the limit for protocol != file where left out because there > was no consensus how the filename construction etc. should be handled.
Okay, it's the latter I was wondering about. Let's leave it for now. Stefan