[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-API] Resetting XCP configuration into factory defaults - simply reset state.db?



Hi,

sorry about the noise, but there IMHO there is no good documentation
about how to reset the configuration of an XCP installation.
Is it ok to just erase the state.db and set the /etc/xensource/pool.conf
to master, to reset the Xen API part of an XCP installation?

As I wrote earlier - because of the VDI state problems I did a host
destroy and now want to simply re-add the machine (I do not mind about
the old metadata on the machine) without having to reinstall the whole
system.

Thanks for your support,
Jakob


Am 03.12.11 23:33, schrieb Jakob Praher:
> Dear Scott,
> Dear List,
>
> @Scott: that is good to now. What means later xapi builds? I am using
> XCP 1.1. I tried various attemps (even restarting the machine - I think
> also after the host-forget command).
>
> Now I am currenlty facing the converse issue: Since I did a host-destroy
> (in my last attempt to correct the power-state), the host is erased from
> the resource pool metadata. But I want to simply add the again working
> host to its old resource pool without having to make a clean sweep.
>
> What is a good way to rejoin a destroyed host without compromising the
> resource pool and the current master?
> Can I somehow convert a server that was formerly part of resource pool
> to be standalone again and then proceed as if it was a fresh installation?
>
> Thanks,
> Jakob
>
> Am 23.11.11 22:05, schrieb Dave Scott:
>> Hi,
>>
>> I believe Jon's advice in this earlier thread is still valid:
>>
>> http://old-list-archives.xen.org/archives/html/xen-api/2011-02/msg00066.html
>>
>> FYI in later xapi builds a "xe host-forget" followed by a "service xapi 
>> restart" would also fix it.
>>
>> HTH,
>> Dave
>>
>>> -----Original Message-----
>>> From: xen-api-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-api-
>>> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jakob Praher
>>> Sent: 23 November 2011 19:37
>>> To: xen-api@xxxxxxxxxxxxxxxxxxx
>>> Subject: [Xen-API] Fwd: Issue XCP 1.1: Shared LVM SR - unavailable host
>>> leaves VDI attached RW (xe vdi-introduce not available)
>>>
>>> Dear list,
>>>
>>> We observed the following issue in conjunction w/ XCP 1.1 which is a
>>> _severe_ problem.
>>>
>>> Our environment:
>>> - Two XCP 1.1 hosts in the same resource pool
>>> - Shared LVM based storage repository based on DRBD
>>> - VMs running on both systems stored on the shared SR
>>>
>>> If suddenly one host dies unexpectedly (e.g. hardware defect, power
>>> issue) the metadata still assumes the VMs that were running on the
>>> unavailable host are in power-state running.
>>>
>>> After ensuring the master to be the still available host and manually
>>> resetting the power-state of the VMs running on the unavailable host we
>>> faced the following problem:
>>>
>>>  - The VDI state was still readwrite attached allthough the whole host
>>> was unavailable. This also preserved when we made the system to forget
>>> the unavailable host.
>>>
>>>  - Even worse "xe vdi-introduce" does not work since it is not
>>> supported
>>> by the LVM backend. All other tricks even snapshotting the disk does
>>> not
>>> work, since XAPI tries to contact the dead host and this fails.
>>>
>>> The problem is that as long the host is down for maintenance the VMs
>>> are
>>> in a defective state!
>>>
>>> What is the way out of this dilemma?
>>>
>>> Best regards,
>>> Jakob
>>>
>>> P.S.: I have not only restarted xapi but also the available host.
>>>
>>> _______________________________________________
>>> xen-api mailing list
>>> xen-api@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/mailman/listinfo/xen-api
>
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.