Hi Lukas, Is it okay for you to have meeting on Monday 8PM IST, which is somewhere around 3:30PM CET ?
Thanks, Chandrashekar -----Original Message----- From: avocado-devel-boun...@redhat.com [mailto:avocado-devel-boun...@redhat.com] On Behalf Of Lukáš Doktor Sent: Friday, February 9, 2018 1:54 AM To: chand...@codeaurora.org; email@example.com Subject: Re: [Avocado-devel] How to create a custom config image to import and run the tests Dne 8.2.2018 v 16:55 chand...@codeaurora.org napsal(a): > I got something from Fedora 10.i386 and would be trying it. > > - 10.i386: > no virtio_net, virtio_blk, e1000 > no balloon_check > os_variant = fedora10 > vm_arch_name = i686 > Hello Candrashekar, I'm glad you're making progress. I'd suggest something newer as F10 is quite old and some options might not make sense for todays kernels (eg. no virtio_blk...). Anyway the way Avocado-vt config usually work is to chose the os which is the closest to your one by `--vt-guest-os` ($AVOCADO_DATA/avocado-vt/backends/qemu/cfg/guest-os.cfg), optionally set the `--vt-arch` and `--vt-machine-type` ($AVOCADO_DATA/avocado-vt/backends/qemu/cfg/machines.cfg). If you require different nic_model ($AVOCADO_DATA/avocado-vt/backends/qemu/cfg/guest-hw.cfg), image_type or such you can set it in `/etc/avocado/conf.d/vt.conf`. In runtime, you can tweak all Avocado-vt params directly via `--vt-extra-params`, for example `--vt-extra-params mem=2048 smp=8 nettype=bridge` which directly overrides everything set by config/options. Btw if you are curious how it all works it's quite simple. The Avocado-vt plugin parses $AVOCADO_DATA/avocado-vt/backends/qemu/cfg/tests.cfg and creates list of dictionaries containing all possible variants. Then it adds filters defined by `--vt-guest-os` or config (nettype) which removes the non-matching variants. In the end it adds filters defined by test-ids (`avocado run boot` -> `filter-only boot`) which should resolve into a single `boot.Fedora.10.i386.i440fx.smp2.ide.rtl8139` variant with resulting dict with params like `smp=2` or `nic_model=rtl8139`. These params are printed at the beginning of the test and you can force-override them by `--vt-extra-params`. As for the cfg processing, the `tests.cfg` includes `tests-shared.cfg` which basically includes all the other configs in the order they are specified. The order is quite important, because the later variants can override values of the previous variants so for example in `base.cfg` you have `mem=1024` but in some tests in `subtests.cfg` this value gets overridden to amount that is required there. The files are organized only for humans, computer does not care and you can define new machine types in `subtest.cfg` as well as you can create new test cases in `guest-os.cfg`. Anyway I'd recommend reading the documentation (at least skim through it) as most things are there. To better understand how it works you can also try using `virttest/cartesian_config.py $AVOCADO_DATA/avocado-vt/backends/qemu/cfg/tests.cfg -c` followed by some filters which gives you the resulting dicts. Regards, Lukáš Doktor PS: I'm in CET timezone but tomorrow I'll be mainly offline. But next week we can schedule a meeting if you feel like it'd be useful. PPS: If you simply want to test your features using existing tests, you don't really need to understand the cartesian and could simply use avocado as a black box providing your image and expect it to work. But if you want to understand the logic behind, cartesian is quite important part of it. > > Thanks, > Chandrashekar > > -----Original Message----- > From: avocado-devel-boun...@redhat.com > [mailto:avocado-devel-boun...@redhat.com] On Behalf Of > chand...@codeaurora.org > Sent: Thursday, February 8, 2018 9:17 PM > To: 'Lukáš Doktor' <ldok...@redhat.com>; firstname.lastname@example.org > Subject: Re: [Avocado-devel] How to create a custom config image to > import and run the tests > > Hi Lukas, > > I was able to the custom config file to include the disk.img and import using > "unattended_install.import.import.default_install.aio_native". > > Is there a way where I can mention the hardware, machine, os and tests in one > config file ? > > So that we don't have to manipulate many config files. > > Thanks, > Chandrashekar > > > -----Original Message----- > From: avocado-devel-boun...@redhat.com > [mailto:avocado-devel-boun...@redhat.com] On Behalf Of > chand...@codeaurora.org > Sent: Wednesday, February 7, 2018 11:52 PM > To: 'Lukáš Doktor' <ldok...@redhat.com>; email@example.com > Subject: Re: [Avocado-devel] How to create a custom config image to > import and run the tests > > Thanks a lot! > > Now my setup is completely messed up, probably I would reinstall and try the > same. > > ~cshastri > > -----Original Message----- > From: Lukáš Doktor [mailto:ldok...@redhat.com] > Sent: Wednesday, February 7, 2018 11:26 PM > To: chand...@codeaurora.org; firstname.lastname@example.org > Subject: Re: [Avocado-devel] How to create a custom config image to > import and run the tests > > Dne 7.2.2018 v 18:33 chand...@codeaurora.org napsal(a): >> Hi, >> >> The shared folder is not created when I install the avocado and after >> running the vt-bootstrap, I manually created the >> shared/cfg/guest-os/Linux/LinuxCustom/foo.cfg >> > > The shared folder has to be somewhere. When installed from RPM or by `make > install` it's usually in `/usr/share/avocado-plugins-vt/shared`, when > executed using `make link` (on development machine I'd recommend this) it's > directly in the sources `$AVOCADO_VT_SOURCES/share`. > > After `vt-bootstrap` those changes should be visible in > `$avocado_data_dir/avocado-vt/backends/$provider/cfg/guest-os.cfg` where > `$avocado_data_dir` can be found in `avocado config --datadir` and $provider` > means the provider you chose via `--vt-type`, by default it's qemu (and I'd > recommend starting with this one, it's way easier at first). > >> cat shared/cfg/guest-os/Linux/LinuxCustom/foo.cfg >> - FooLinux: >> image_name = images/foo-linux >>> It doesn't list the foo guest. > > Most certainly you created this dir in a wrong location. Once you do that it > should work (there is even LinuxCustom readme describing some useful > attributes). Anyway I'd recommend using similar existing profile, which > should give you better results. Simply pick something with similar init, > packaging-app and kernel features and that's it. On the other hand starting > fresh with LinuxCustom might avoid some possible wrong assumptions :-) Just > keep in mind some tests are tagged `only RHEL` or `no JeOS` which might > eliminate them from your `LinuxCustom` execution (there is a great difference > in `avocado list` and `avocado list --vt-guest-os RHEL.7.devel` (I like the > `RHEL.7.devel` because it generally means any RHEL.7-like system, which is > basically any newer Fedora, SuSE, CentOS or even RHEL :D). > > Regards, > Lukáš > >> >> Thanks, >> Chandrashekar >> >> -----Original Message----- >> From: avocado-devel-boun...@redhat.com >> [mailto:avocado-devel-boun...@redhat.com] On Behalf Of Lukáš Doktor >> Sent: Wednesday, February 7, 2018 9:51 PM >> To: chand...@codeaurora.org; email@example.com >> Subject: Re: [Avocado-devel] How to create a custom config image to >> import and run the tests >> >> Dne 31.1.2018 v 16:49 chand...@codeaurora.org napsal(a): >>> How to add the user define guest and boot from the existing disk.img >>> and run the minimal tests, like >>> >>> I don't include migration, nfs, glusterfs, etc. >>> >>> Could you please help me on the same. >>> >>> Thanks, >>> Chandrashekar >>> >> >> Hello Chandrashekar, >> >> I assume you're talking about Avocado-vt tests, right? There the disk image >> is specified by the `--vt-guest-os` "profile" which are defined in >> `$AVOCADO_VT/shared/cfg/guest-os/*` config files. You can see that there are >> many values set which change many aspects throughout the test execution >> mainly about the allowed devices (virtio_blk/virtio_scsi/...) or ways to >> interact with os (yum, apt-get, whatever windows allows...), but many things >> are common even across different profiles. >> >> So, to answer your question, simply find the closest match either by looking >> through the files or using `avocado list --vt-list-guests` (probably >> combined with `--vt-arch aarch64 --vt-machine-type arm64-pci`) which lists >> the profiles available for given arch/machine-type. Note that differences >> between architectures are usually quite small so if need for example >> `debian` you can copy the `x86_64` profile and change the values that are >> defined there and it should "mainly" work. Keep in mind you have to run >> `avocado vt-bootstrap` to propagate the changes in `$AVOCADO_VT/shared` to >> Avocado-vt. >> >> Once you pick a suitable profile you can simply run `avocado --show all run >> --vt-guest-os XXX -- boot` which will most probably fail saying "image >> /foo/bar/baz/XXX.qcow2 not found" which gives you the location where you >> need to put your image. Once the image is there Avocado will assume it's the >> correct image of that OS, it'll create a backup and use it in tests usually >> reverting back after testing. There are some exceptions where the image gets >> overridden and that are mainly the `unattended_install` tests which try to >> install that kind of OS using the chosen media (cdrom, url, ...). >> >> Note that for start you should be able to use the default, which is >> `JeOS.27` which is essentially a stripped out Fedora 27 shipped by us for >> all main architectures (aarch64, ppc64, ppc64le, x86_64 and s390x) so >> `avocado run boot` should usually work. >> >> Happy testing, >> Lukáš >> >> > > > > > > >