usability major bug?

[Oleg Artemiev]

I have to reboot Qubes R3.2 a few times a day. What do I do wrong?

reproduceable: daily on my workstation

impact: ability to run 10-15 VMs is not guaranteed . My harware is
strong enough to be able to run that count of qubes (it is normal to
me).

Has this been already reported?

--
Bye.Olli.
gpg --search-keys grey_olli , use key w/ fingerprint below:
Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

[Holger Levsen]

Hi Oleg,

you missed on important bit of information:

On Wed, Mar 22, 2017 at 12:12:58PM +0300, Oleg Artemiev wrote:
> I have to reboot Qubes R3.2 a few times a day. What do I do wrong?

why do you have to reboot?

> reproduceable: daily on my workstation
>
> impact: ability to run 10-15 VMs is not guaranteed . My harware is
> strong enough to be able to run that count of qubes (it is normal to
> me).

--
cheers,
Holger

[Oleg Artemiev]

On Wed, Mar 22, 2017 at 1:52 PM, Holger Levsen <hol...@layer-acht.org> wrote:
> Hi Oleg,
>
> you missed on important bit of information:
>
> On Wed, Mar 22, 2017 at 12:12:58PM +0300, Oleg Artemiev wrote:
>> I have to reboot Qubes R3.2 a few times a day. What do I do wrong?
>
> why do you have to reboot?

Cost of reboot in __understanding__ what the hell is the reason is
less than cost of restoring correct state after reboot.

I feel like queue in some code is failing to grow.
Usually I detect such things via load testing.

As a QA professional I'm ready to commit to:

1) run (some times within free time) load tests
2) provide nummeric results (not raw logs!) on my dom0 - no VM names.
Only symbolic handles I'm ok to publish are qubes OS internals - no VM
names and similar personal stuff.

Only if I do understand the code . Thus the load testing code and
final summary report must be available to me + no pipes to pass
numbers via any protocol into internet or tor.
Better if applied by python, nodejs,bash, or ruby or erlang language .

>> reproduceable: daily on my workstation
>>
>> impact: ability to run 10-15 VMs is not guaranteed . My harware is
>> strong enough to be able to run that count of qubes (it is normal to
>> me).
>
>
> --
> cheers,
> Holger

[Holger Levsen]

On Wed, Mar 22, 2017 at 03:08:00PM +0300, Oleg Artemiev wrote:
> > why do you have to reboot?
> Cost of reboot in __understanding__ what the hell is the reason is
> less than cost of restoring correct state after reboot.
>
> I feel like queue in some code is failing to grow.
> Usually I detect such things via load testing.
>
> As a QA professional I'm ready to commit to:
>
> 1) run (some times within free time) load tests
> 2) provide nummeric results (not raw logs!) on my dom0 - no VM names.
> Only symbolic handles I'm ok to publish are qubes OS internals - no VM
> names and similar personal stuff.
>
> Only if I do understand the code . Thus the load testing code and
> final summary report must be available to me + no pipes to pass
> numbers via any protocol into internet or tor.
> Better if applied by python, nodejs,bash, or ruby or erlang language .

let me try again:

- how does the reboots happen? you said "you have to reboot", did you mean the
machine just sponteaniously reboots and thus forces you into reboots?
- is there anything special you are doing when this happen or does it happen
"randomly"?


--
cheers,
Holger

[Jean-Philippe Ouellet]

On Wed, Mar 22, 2017 at 8:08 AM, Oleg Artemiev <grey...@gmail.com> wrote:
> On Wed, Mar 22, 2017 at 1:52 PM, Holger Levsen <hol...@layer-acht.org> wrote:
>> Hi Oleg,
>>
>> you missed on important bit of information:
>>
>> On Wed, Mar 22, 2017 at 12:12:58PM +0300, Oleg Artemiev wrote:
>>> I have to reboot Qubes R3.2 a few times a day. What do I do wrong?
>>
>> why do you have to reboot?
> Cost of reboot in __understanding__ what the hell is the reason is
> less than cost of restoring correct state after reboot.

No, we understand the cost of rebooting, but you have not stated why
you do reboot.

What specific symptom(s) do you observe before rebooting which causes
you to feel the need to reboot?

[Oleg Artemiev]

On Wed, Mar 22, 2017 at 3:32 PM, Holger Levsen <hol...@layer-acht.org> wrote:
> On Wed, Mar 22, 2017 at 03:08:00PM +0300, Oleg Artemiev wrote:
>> > why do you have to reboot?
>> Cost of reboot in __understanding__ what the hell is the reason is
>> less than cost of restoring correct state after reboot.
>>
>> I feel like queue in some code is failing to grow.
>> Usually I detect such things via load testing.
>>
>> As a QA professional I'm ready to commit to:
>>
>> 1) run (some times within free time) load tests
>> 2) provide nummeric results (not raw logs!) on my dom0 - no VM names.
>> Only symbolic handles I'm ok to publish are qubes OS internals - no VM
>> names and similar personal stuff.
>>
>> Only if I do understand the code . Thus the load testing code and
>> final summary report must be available to me + no pipes to pass
>> numbers via any protocol into internet or tor.
>> Better if applied by python, nodejs,bash, or ruby or erlang language .
>
> let me try again:
>
> - how does the reboots happen?

I do reboot manually.

> you said "you have to reboot", did you mean the
> machine just sponteaniously reboots and thus forces you into reboots?

No. This _USABILITY_ issue. I need this functionality. It is broken.
=> reboot manually

> - is there anything special you are doing when this happen or does it happen
> "randomly"?

I've no time to provide detailed report within nearest week and till
this is not subject to some load testing - I think that my time spent
to report will came into a timewaste.

[Unman]

Fair enough, but you *still* haven't said what symptoms there are
that force you to reboot.

I'm currently running 20 VMs without a problem, and I use disposableVM
a lot, so your 10-15 should be manageable.
It would be far more useful if you actually gave some detail on your
specs, what symptoms you see and what functionality you think is
broke, along with some suggestion as to how you reproduce the problem.
As a QA professional you will know how important this information is.