The jobs were scheduled with --systype Virtual for the TCMS run 25267.
See https://beaker.engineering.redhat.com/jobs/105669 for successfull job for the same run.
All of them aborted, some immediately, some after short time.
Sorry, Those virtual systems can't be scheduled as regular recipes. Those
guest=* systems are simply place holders in dns for virtual machines which are
dynamically brought up on other test systems.
You should use <hypervisor op="=" value="kvm"/> for example.
Sorry for the confusion but we have two different types of virtual in beaker
right now. Eventually we will get rid of the need to have all those place
holder dns names. But that won't be for a while.
can we keep this open as an RFE for better logging?
Until the placeholders go away as you mention, could Beaker at least add a simple log line pointing people how to work with the virtuals (?)
Platform QE is experimenting if we can run our regular tiers on KVM (and thus other virtuals) so anything which will make it easier is highly welcome.
And it never hurts to have a proper error message on what's going on :-)
(In reply to comment #2)
> Hi Bill,
> can we keep this open as an RFE for better logging?
> Until the placeholders go away as you mention, could Beaker at least add a
> simple log line pointing people how to work with the virtuals (?)
> Platform QE is experimenting if we can run our regular tiers on KVM (and thus
> other virtuals) so anything which will make it easier is highly welcome.
> And it never hurts to have a proper error message on what's going on :-)
I don't understand. There is no logging I could capture.
OK, maybe I'm misunderstanding how Beaker works.
My line of thinking is that
* user schedules a job the way Zbysek did
* Beaker knows it's going to fail, because without '<hypervisor op="=" value="kvm"/>' the operation is not supported ATM
* jobs get silently aborted instead of an error message visible in Web UI that this is not supported and there's proper way to do it
So scheduler (?) could write virt-unsupported.log (or similar) saying "what you're trying to do is unsupported because of <link>. See <link>documentation</link>.
Or is that not possible with the architecture we have ATM?
There are lots of combinations that don't make sense. The scheduler simply states that it doesn't match anything.
Shouldn't beaker itself schedule jobs with <hypervisor op="=" value="kvm"/> for example, when using --systype=virtual within XML instead of just scheduling on nonexistin guest-* machines ?
We have to fix a couple of things first.
We need to update scheduler to not need static guest names when using <guest> recipes, then remove the old guest-* entries.
Then systype=virtual will mean the actual real virtual machines that are usable.
Why not just hide them? Is there any reason to have them listed?
We may still want them linked from Recipe page (May be just for consistency) but on list of systems these are just pointless.
Could we just use better defaults for filters and allow user to add/remove clauses in filter form?
Are there any other systems to hide by default?
For example one is usually not interested in Broken (and almost never in Removed) machines unless owner, lab-admin or in dire need of certain hardware (yes, that's what Available list is for...)
Also having predefined filters would allow easy moving among Free/Available/All system views by simply removing a clause from filter.
I am sometimes looking for a Free machine but when there is none I would have to go to Available page and repeat the query (but I just do s/Free/Avaialble/ on the URL) and eventually repeat with All to have the machine Loaned to me.
This may be better served by providing links: Free > Available > All on the system's page (for example next to "Toggle Search" link.)
The only reason I can think where having them them listed is useful, is when diagnosing install problems related to guest install. (i.e if there are no virt machine then there will be problems...).
I like the idea of the link to the same search via Free/Available/All.
We have finally fixed this (as bug 655009). There will be no more type=Virtual.
*** This bug has been marked as a duplicate of bug 655009 ***