From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0F2N-0001cz-0I for qemu-devel@nongnu.org; Fri, 28 Oct 2016 17:50:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c0F2J-0002yj-T8 for qemu-devel@nongnu.org; Fri, 28 Oct 2016 17:50:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53618) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c0F2J-0002ye-LM for qemu-devel@nongnu.org; Fri, 28 Oct 2016 17:50:03 -0400 Date: Fri, 28 Oct 2016 17:50:00 -0400 From: Jeff Cody Message-ID: <20161028215000.GL2677@localhost.localdomain> References: <1477520585-8418-1-git-send-email-ashish.mittal@veritas.com> <20161027072948.GC5595@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2] block/vxhs: Add Veritas HyperScale VxHS block device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rakesh Ranjan Cc: ashish mittal , "Daniel P. Berrange" , "qemu-devel@nongnu.org" , Paolo Bonzini , Kevin Wolf , Markus Armbruster , "famz@redhat.com" , Ashish Mittal , Stefan Hajnoczi , Buddhi Madhav , Ketan Nilangekar , Abhijit Dey , "Venkatesha M.G." On Fri, Oct 28, 2016 at 01:26:41AM +0000, Rakesh Ranjan wrote: > Hi Jeff etc al, >=20 > Thanks a lot for your due diligence to review the code changes throughl= y > and providing comments, suggestions to improve. We are completely on to= p > of this and have already started to expedite the overall development. >=20 > We would like to get you help regarding the applicability of qemu-iotes= ts > test harness against a QEMU block driver which doesn=B9t support create > operation. Where we can find the detailed document regarding qemu-iotes= ts > test harness and and it=B9s dependency on a particular block driver? >=20 > We have enhanced the test server utility (qnio_server) a bit and conduc= ted > manual tests, which mainly includes qemu-img convert and qemu-io read a= nd > write operations. >=20 > # libqnio/src/test/ >=20 > @ Create vDisk file of size 10G > =20 > # ./create_vdisk.sh > Usage: create_vdisk >=20 >=20 > # ./create_vdisk.sh /qemublk_test/vDisk1 10240 >=20 >=20 > # ls -lhs /qemublk_test/vDisk1 > 1.1M -rw-r--r-- 1 root root 10G Oct 27 17:02 /qemublk_test/vDisk1 >=20 >=20 >=20 > @ Start qnio_server >=20 > # ./qnio_server -h > Usage: qnio_server [-d ] [-p] [-v] [-h] > d -> Vdisk directory > p -> Run commands in separate thread > h -> Help > v -> Verbose >=20 >=20 > # ./qnio_server -d /qemublk_test/ >=20 >=20 >=20 > @ Convert qcow2 image to vxhs raw format >=20 > # ./qemu-img convert -f qcow2 -O raw -n /qemublk_test/centos-64.qcow2 > vxhs://127.0.0.1:9999/vDisk1 >=20 Hi Rakesh, The qemu-iotests are located in the qemu tree, under 'tests/qemu-iotests'= . I don't know of any formal documenation out here, but here are the basics= : To run an individual iotest, you can run the test from within the tests/qemu-iotests directory, e.g.: # cd tests/qemu-iotests # ./check -qcow2 002 What this will do is run the test case 002 with the format qcow2. The output of that test is checked against 002.out, and if there are differences, an error is reported. What is implicit in the above check command is the protocol type of 'file= '. If you wanted to run that test using a different protocol (for instance, 'nfs'), you can do: # ./check -qcow2 -nfs 002 You need to extend qemu-iotests to be aware of the vxhs:// protocol. To do this, you'll need to modify these files: tests/qemu-iotests/common.rc tests/qemu-iotests/common If you search for some of the other protocol drivers, you should see what you need to change; for instance, 'sheepdog', 'nfs', 'ssh', etc.. are all protocol drivers. One difference is, as you noted, that you cannot create an image using yo= ur protocol. This means you will need to either: A) Let the test framework create the test image like normal, and then hav= e the test script launch the test QNIO server, B) Do the image creation, and server launch, manually outside the script. This isn't optimal because then the testers (e.g. me, and other block maintainers) need to remember what steps to perform. For the basis of a simple test, you can look at test 002. It should be a good starting point. You'll need to create a new test as a file named af= ter the existing tests (you need the ??? and ???.out files), and then modify = the 'group' file to include the test). Generally, it is best if the test if a separate patch in the series. Jeff