[libvirt] [PATCH 1/1] tests/virsh-checkpoint/snapshot: changing 'sed' out filtering
Daniel Henrique Barboza
danielhb413 at gmail.com
Thu Aug 1 12:49:55 UTC 2019
On 8/1/19 8:43 AM, Eric Blake wrote:
> On 8/1/19 6:30 AM, Eric Blake wrote:
>> On 7/31/19 4:58 PM, Daniel Henrique Barboza wrote:
>>> There is a chance that the current sed filtering used in
>>> these new tests might fail in some machines due to the
>>> repetition of the 'virsh #' prompt at the same line,
>>> together with valid output that shouldn't be filtered.
>> Ah, so it is a data race where the prompts produced by virsh don't
>> always flush in relation to other data being output.
>>
>> Yes, eating all blank lines and just the prompt sub-string rather than
>> the entire line with a prompt is a nice fix, and safe for freeze.
> Actually, when I apply your patch, I run into failures on my end:
>
> --- exp 2019-08-01 06:37:33.108617030 -0500
> +++ out.cooked 2019-08-01 06:37:33.110617032 -0500
> @@ -1,5 +1,11 @@
> + snapshot-create test --redefine s2.xml --validate
> + echo --err marker
> + # This is the right order
> + snapshot-create test --redefine s3.xml --validate
> Domain snapshot s3 created from 's3.xml'
> + snapshot-create test --redefine s2.xml --current --validate
> Domain snapshot s2 created from 's2.xml'
> + snapshot-info test --current
> Name: s2
> Domain: test
> Current: yes
> FAIL virsh-snapshot (exit status: 1)
>
> So I think the difference is that your dev box is not echoing the
> commands, and the real problem is that the test is dependent on the
> current environment (is there some configuration file that determines
> whether virsh in batch mode will echo what is typed?)
>
> It would be possible to change the tests to use
> virsh ... 'sequence of commands'
> instead of
> virsh ... <<EOF
> sequence of commands
> EOF
>
> (in fact, that's what we do in the first half of the script); when you
> do that, you no longer get the 'virsh #' prompts, nor any problem with
> command echo. But before doing that, I'd still like to understand what
> is different about your environment that suppresses the echo in the
> first place, to encounter the output data race.
Sure. This is how I build Libvirt and run the tests:
./autogen.sh --prefix=$PWD/usr
make -j && make syntax-check && make check
General machine info follows:
[danielhb at rekt libvirt]$ uname -a
Linux rekt 5.1.15-300.fc30.x86_64 #1 SMP Tue Jun 25 14:07:22 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
[danielhb at rekt libvirt]$
[danielhb at rekt libvirt]$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 39 bits physical, 48 bits virtual
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 142
Model name: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
Stepping: 10
CPU MHz: 3200.113
CPU max MHz: 4200.0000
CPU min MHz: 400.0000
BogoMIPS: 4224.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni
pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr
pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave
avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single
pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad
fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed
adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida
arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
[danielhb at rekt libvirt]$
[danielhb at rekt libvirt]$ lsb_release -a
LSB Version:
:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: Fedora
Description: Fedora release 30 (Thirty)
Release: 30
Codename: Thirty
[danielhb at rekt libvirt]$
[danielhb at rekt libvirt]$ cat /proc/meminfo
MemTotal: 32682444 kB
MemFree: 2585380 kB
MemAvailable: 22865820 kB
Buffers: 1780684 kB
Cached: 19278004 kB
SwapCached: 768 kB
Active: 18504408 kB
Inactive: 9039088 kB
Active(anon): 6574348 kB
Inactive(anon): 1445640 kB
Active(file): 11930060 kB
Inactive(file): 7593448 kB
Unevictable: 656044 kB
Mlocked: 64 kB
SwapTotal: 16408572 kB
SwapFree: 16400452 kB
Dirty: 2220 kB
Writeback: 0 kB
AnonPages: 7140812 kB
Mapped: 1772148 kB
Shmem: 1535216 kB
KReclaimable: 1232012 kB
Slab: 1529188 kB
SReclaimable: 1232012 kB
SUnreclaim: 297176 kB
KernelStack: 29600 kB
PageTables: 102972 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 32749792 kB
Committed_AS: 27285012 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
Percpu: 12608 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 976512 kB
DirectMap2M: 29175808 kB
DirectMap1G: 4194304 kB
I'll see if I can get different results running the tests in a Power 8/9
server.
I'll also do a clean 'git clone' run to see if the results differ.
More information about the libvir-list
mailing list