On 03/14/2013 07:42 AM, lei yang wrote:
Hi Chris
I have boot well with my custom img (my kernel and rootfs) with qemu test,
now I want to try libvirt test, I have some question, can you help me?
This should be possible, though I have not tried it using the test
runner, only the autotest client and using a custom libvirt/cfg/tests.cfg
1) Firstly I just tried Jeos for it I get below error, it seems I need some
extra steps to do before testing?
Did you run libvirt/get_started.py?
#run -t libvirt
....................
....................
Command</usr/bin/virsh undefine virt-tests-vm1> failed, rc=1, Command
returned non-zero exit status
* Command:
/usr/bin/virsh undefine virt-tests-vm1
Exit status: 1
Duration: 0.00803685188293
stderr:
error: failed to get domain 'virt-tests-vm1'
error: Domain not found: no domain with matching name 'virt-tests-vm1'
I would need more context to see why this particular test is failing.
The default set when you run 'run -t libvirt' should start with:
# ./run -t libvirt
SETUP: PASS (1.64 s)
DATA DIR: /var/lib/virt_test
DEBUG LOG:
/usr/local/autotest/client/tests/virt/logs/run-2013-03-14-09.50.43/debug.log
TESTS: 28
(1/28) unattended_install.import.import: PASS
...
(28/28) remove_guest.without_disk: PASS (10.38 s)
Which creates a new guest named 'virt-tests-vm1' and attaches it to the
uncompressed JeOS image. The last test removes the guest definition,
but leaves the image in place.
Which branch are you running from?
Does this work:
# ./run -t libvirt --tests "unattended_install.import.import" ?
2) if I use my custom kernel.img and rootfs.img, is there another other
config for this? eg: xml for the guest. and then virsh start the guest
manually? or simple way than this I don't know
We have support for many other OS types and versions, however they're
all intended to be installed under test control (which builds a
virt-install command). This helps to ensure that libvirt's guest
hardware definition matches what the image is setup for.
You can get around this to a degree with the unattended_install.import
variants, but the boot loader, kernel, and initrd would all need to be
embedded within the image We don't yet have support for specifying a
custom kernel, initrd, and/or rootfs image to virt-install outside the
context of an installer (i.e. the scope of the 'kernel' & 'initrd' param's.)
That said, support for newer virt-install's --boot option would be a
nice feature to have. You're welcome to open a feature/enhancement
issue and add it to this tracking issue:
https://github.com/autotest/virt-test/issues/64 or add it yourself. I
believe it would just need some new parsing logic added to libvirt_vm's
make_create_command() method and a new parameter to alter the scope of
the 'kernel' & 'initrd' parameters.
--
Chris Evich, RHCA, RHCE, RHCDS, RHCSS
Quality Assurance Engineer
e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
