On 03/14/2014 08:00 AM, Lucas Meneghel Rodrigues wrote: > Hi guys, I'm writing this because I wanted some input from users of > our test suite. From time to time, we have people arguing over some > change in the default behavior, and it's frequently difficult to have > a well informed decision on how the changes affect users. > > Cases in point: > > 1) Always keep screendumps > > https://github.com/autotest/virt-test/pull/1497 > > Keep screendumps by default. Xu argues that keeping the dumps is > useful to notice video bugs, which I agree. The downsides I see: > > * You actually need someone looking into the dumps to make those bugs > discoverable, I suspect the majority of users won't look at those anyway.
The rule for KVM-QE on analyze autotest log, screendump is one of the important log MUST to check. esp. 1) when a Win VM BSOD, you cant know the MS bug check id by viewing the screen. 2) when autotest cant ssh into guest, need to see screeen to know whether VM fully booted(esp Win, didn't output its booting via serial) > * If the above sentence is true, we'd be spending a lot of disk space, > and while I agree with the general assessment that storage is cheap, > in practice we may be running in systems short on disk space and this > change would mean that disks fill up faster by default, specially in > long tests such as windows install. For someone like Paolo, that runs > a lot of windows installs, I imagine the extra disk consumption will > be significant. Not a lot of disk space: A Windows 2008 VM installation (finish it's installation approx 30 min), consuming 8.0M on my test, on RHEL.6.5 host(I think that wont cost double on other host...) generally speaking, a tower machine would equipped hundreds (or even thousands )of GB, 8.0M is the amount we treat it as tiny. QE Acceptance test for qemu-kvm would run 150+ cases, including 10+ VM installation, and the total log size is about 200M~400M each round(if not qemu core dump during test) Keeping as more logs as possible are important, you wont know when bugs appear, if you suspect a video bug inside a test, but you didn't save the screendumps, you got to reproduce, time is more important compare to the disk spaces. and bugs might not 100% reproducible, you suspect, you might need ten times of reproduce attempt. > > So I see merits in changing, but I'd like to hear other opinions. > > 2) Save screendump per VM pid rather then name > > https://github.com/autotest/virt-test/pull/1491 > > Feng Yang argues that with the current schema we end up merging > screenshots from vms that may be different in configuration. To me, > the problem lies in the fact that different qemu instances don't imply > in different vms in a broader sense, they might just be different > boots of the same vm. Anyway, the direct impact of the patch is that > by having dir Yes, that's true, it could be the exactly same VM in different stage, and here's my POV, standing on making analyzing more convenient: let's take ping-pong Migration as an example: 1) booting a VM(that's say this instance pid is: 1000, called VM1) -> guest screen is started capturing 2) then launch the dest VM as incoming mode(say pid 1100, called VM2) -> blank screen, not captured 3) sending migrate cmd to VM1, when finished, VM1 becomes blank screen and now VM2 is actually the continue state of the origin VM1 -> Okay, now capturing pid_1100_VM2 4) migrate VM2, process like 3), but let's break it into two stage: 4.1) now the dest VM would name VM1, say the new VM1 pid is 1200, -> now pid_1100_VM2 is active, and keep capturing 4.2) migration to VM1 finished, and pid_1200_VM1 is now active -> screendump captured into VM1, and mixing w/ the pid_1000_VM1 Now here comes the problem, it's hard to figure out which picture is captured at which stage for VM1(obviously I am not saying the 1st and the last), we all know migration has multiple phase, pre-migrate, on-the-migrate, post-migrate, when bug occurs, mixing screendumps means difficulty to know the exact step it happen, that would cost more time for QE work. splitting dumps into diff folders by pid, that's the easy way to know at which stage, like above scenario: 1) pre-migrate 2) on-the-migrate 3) post-migrate(VM continue at VM2) much friendly for debug > logs per PID we have more video files, that will take up some > additional encoding time (in my machine, extra 4 seconds per extra > video encoded). This adds up to 3 minutes in my default run, > increasing it from 12 minutes to 15 minutes (25% increase). well, machines can automatically do encode/decode job, but analyze needs human manually and the time you saved in encoding, would result at least double on the later analyze work. -- Best Regards, Xiaoqing Wei _______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
