[Pkg-xen-devel] Bug#680102: More fixes for xen-api in Wheezy

George Shuklin george.shuklin at gmail.com
Sat Jul 7 22:01:15 UTC 2012


On 08.07.2012 00:22, Mike McClurg wrote:
> (CC'ing George Shulkin, and the #680102 bug list)
>
> On Sat, Jul 7, 2012 at 4:37 PM, Thomas Goirand <thomas at goirand.fr> wrote:
>> Hi Mike and Jon,
>>
>> It would be really nice if you could have a look at these 3 pending
>> issues in the Debian bug tracker:
>>
>> #675052: xe vm-memory-target-set does not write target to xenstore
>> #678723: vif-interfaces added to database as PIF's
>> #680102: xcp fails eject host from pool (no /etc/firstboot.d found)
>>
>> It be great to have it fix asap, before the deep freeze of Wheezy.
>>
>> I've been able to fix others already. Other than that, only #680102 is a
>> concern.
> So 680102 is due to there not being an /etc/firstboot.d/ directory (as
> the ticket explains). I think we can fix this issue simply by
> mkdir'ing the directory /etc/firstboot.d/data at some point in xapi's
> installation. This would allow the pool-eject to proceed, but I think
> that there might be problems when the host reboots: since none of the
> firstboot scripts will be called, the host might not reinitialise
> properly.
>
> I think at this point that's all we can hope for. George, can you test
> that creating the /etc/firstboot.d/data directory gets you past the
> current exception your having? If this works good enough, let's make
> this the fix for now.
>
> Jon, do you have any other thoughts on this bug?
>
> Mike


Here results:
# mkdir  /etc/firstboot.d/
# mkdir  /etc/firstboot.d/data
# xe pool-eject host-uuid=a6806a39-442d-f17d-b7a0-59161d18f562

WARNING: Ejecting a host from the pool will reinitialise that host's 
local SRs.
WARNING: Any data contained with the local SRs will be lost.
Type 'yes' to continue
yes
The server failed to handle your request, due to an internal error. The 
given message may give details useful for debugging the problem.
message: Failure("Error while calling xen-cmdline script")


log snippet:

[20120707T21:55:24.695Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject 
R:a16c35a5d1d4|xapi] Raised at forkhelpers.ml:181.30-76 -> 
pervasiveext.ml:22.2-9
[20120707T21:55:24.695Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject 
R:a16c35a5d1d4|backtrace] Raised at pervasives.ml:22.22-33 -> 
list.ml:57.20-23 -> xapi_pool.ml:830.9-125 -> rbac.ml:229.16-23
[20120707T21:55:24.697Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject 
R:a16c35a5d1d4|backtrace] Raised at rbac.ml:238.10-15 -> 
server_helpers.ml:72.10-22
[20120707T21:55:24.697Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject 
R:a16c35a5d1d4|dispatcher] Server_helpers.exec exception_handler: Got 
exception INTERNAL_ERROR: [ Failure("Error while calling xen-cmdline 
script")


My opinion about 'eject' on debian:
1) Clear running VM's
2) Unplug all VBD
3) Unplug all PIF's but management
4) Wipe /var/lib/xcp/state.db
5) Wipe /var/lib/xcp/local.db
6) Keep only management interface data in /var/xcp/network.db
7) restart all xcp services.

During playing with bug lack of '-onsystemboot' flag for xcp I've done 
that operation many times, seems it working without specific problems.

It even works fine without host reboot.





More information about the Pkg-xen-devel mailing list