Cannot start an AppVM when it already exists in Xen database

[marmarek]

Reported by joanna on 28 Jul 2011 18:58 UTC
...which can happen when one tries to start a domain but fails for some reason (e.g. no memory). Later, when attempting to start it again (even if the original problem was resolved, e.g. some memory freed), Qubes fails to start it becuse it exists in Xen DB (as reported by xl list):

[~](joanna@dom0)$ qvm-start work-acct
--> Cleaning volatile image: /var/lib/qubes/appvms/work-acct/volatile.img...
--> Loading the VM (type = AppVM)...
libxl: error: libxl.c:163:libxl_domain_rename domain with name "work-acct" already exists.
cannot make domain: -6
ERROR: Failed to load VM config

[~](joanna@dom0)$ xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  2253     4     r-----    6169.5
netvm                                        1   200     1     -b----     148.5
firewallvm                                   2   200     1     -b----      84.3
work                                         3   659     4     -b----     750.8
work-pub                                     6   546     4     -b----     240.8
red                                          7   542     4     -b----    2070.8                                           
personal                                    11   582     4     -b----     124.2                                           
work-acct                                   14   400     1     --p---       0.0          

Migrated-From: https://wiki.qubes-os.org/ticket/314

[marmarek]

Comment by rafal on 29 Jul 2011 10:55 UTC
I cannot reproduce the problem - any additional hints ? anything suspicious in ~/.xsession-errors (e.g. previous errors from xl ?).
Insufficient memory condition does not result in this - qubes.py first tries to get memory, and if it fails, it does not call xl. And in the xl list output one can see that work-acct is quite alive and well - with the tiny issue that it is paused.
There are two possible explanations:

1. xl create returned nonzero status, but in fact the domain was created
2. xl create went ok, but before qubes.py called domain_unpause, it got an exception
   Both look not likely enough to devise workarounds for them - we need repro scenario.

[marmarek]

Comment by rafal on 29 Jul 2011 10:55 UTC
I cannot reproduce the problem - any additional hints ? anything suspicious in ~/.xsession-errors (e.g. previous errors from xl ?).
Insufficient memory condition does not result in this - qubes.py first tries to get memory, and if it fails, it does not call xl. And in the xl list output one can see that work-acct is quite alive and well - with the tiny issue that it is paused.
There are two possible explanations:

1. xl create returned nonzero status, but in fact the domain was created
2. xl create went ok, but before qubes.py called domain_unpause, it got an exception
   Both look not likely enough to devise workarounds for them - we need repro scenario.

[marmarek]

Modified by joanna on 30 Jul 2011 09:20 UTC

[marmarek]

Modified by joanna on 30 Jul 2011 09:20 UTC

[marmarek]

Modified by joanna on 12 Sep 2011 07:51 UTC

[marmarek]

Modified by joanna on 12 Sep 2011 07:51 UTC

[marmarek]

Comment by joanna on 12 Sep 2011 14:37 UTC
To reproduce:

1. Start a driver domain
2. Shut it down: qvm-run --shutdown
3. Immediately when VM disappears from the manager/qvm-ls, try to start it again (via qvm-start)

[marmarek]

Comment by joanna on 12 Sep 2011 14:37 UTC
To reproduce:

1. Start a driver domain
2. Shut it down: qvm-run --shutdown
3. Immediately when VM disappears from the manager/qvm-ls, try to start it again (via qvm-start)

[marmarek]

Modified by marmarek on 13 Sep 2011 16:41 UTC

[marmarek]

Modified by marmarek on 13 Sep 2011 16:41 UTC

[marmarek]

Comment by marmarek on 13 Sep 2011 17:13 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=0ce7336cadc29f8cdcfbd8637d86b412da58860b

[marmarek]

Comment by marmarek on 13 Sep 2011 17:13 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=0ce7336cadc29f8cdcfbd8637d86b412da58860b