In the process of working with
XenServer, you can change its configuration in different ways.
Starting from the
XenCenter graphical utility and the
xe console command, ending with direct intervention in the XML config.
I would like to talk about the latter with you.
Not all desired actions can be performed using standard utilities. But changing the configuration directly, you can do everything.
After analyzing the contents of the file /var/xapi/state.db, you can even make changes that are not provided by the manufacturer or license.
')
As you probably know, the XenServer API
hub is xapi daemons.
Their motility, in terms of storage configuration, is as follows:
1. Start XAPI
2. Load XML state.db into memory
3. Work (at this time all changes occur in memory)
4. Stop XAPI
5. Writing to state.db in XML
Since XAPI cuts unauthorized changes “on the go”, it is better to perform actions directly with the file, stopping the
xapi service for this.
But here come into force several "BUT".
The biggest BUT is the inconvenience of processing the file with
vi and other editors.
BUT secondary, but no less problematic: For XenServer, the sequence of attributes in XML is critical. Therefore, the standard parsing methods disappear.
For easy searching and changing the parameters in this file, I created the xmlsh.py
utility.With it, you can navigate through the XML file as a directory tree and change the necessary parameters. In terms of implementation, it is a small command interpreter, knowing such commands as ls, cd, set, etc. The complete list is obtained with the help command.
I hope that XenServer administrators will like this utility.
Well, now back to the "abnormal programming."
During the creation of the utility, I was faced with a mass of "ideological" difficulties.
And above all, how XML processing is implemented on python. Since we are limited to version 2.4 (on XenServer), we have 2 libraries at our disposal: dom / minidom and ElementTree.
One of them has convenient inheritance and the second is a transparent parsing system, which allows you to override the basic methods for implementing “OrderedDict” (Why? About this later).
So I had to use both:
minidom is used as the basis for “dynamic movement” and content display.
ElementTree is used only for editing and writing a file.
All this is a necessary measure due to the dependence of XenServer on the order of attributes in the tag (which is, by the way, non-compliance with the standard).
Thus, to force ElementTree to behave "inadequately", the following overrides were needed:
if ( ver [ 0 ] == "2" ) :
#Ordered atributes tree building for Python 2.4
def _start ( self , tag, attrib_in ) :
fixname = self ._fixname
tag = fixname ( tag )
attrib = odict ( )
for key, value in attrib_in. items ( ) :
attrib [ fixname ( key ) ] = self ._fixtext ( value )
return self ._target. start ( tag, attrib )
def _start_list ( self , tag, attrib_in ) :
fixname = self ._fixname
tag = fixname ( tag )
attrib = odict ( )
if attrib_in:
for i in range ( 0 , len ( attrib_in ) , 2 ) :
attrib [ fixname ( attrib_in [ i ] ) ] = attrib_in [ i + 1 ]
return self ._target. start ( tag, attrib )
#Replace base function with mine
etree. XMLTreeBuilder ._start_list = _start_list
etree. XMLTreeBuilder ._strt = _start
The main change in these two methods: we replace the standard dict with odict, which allows us to memorize the sequence of the entries in the list.
You can see the secondary change in the code below: function substitution
etree.ElementTree._write=_write
and method substitution
etree._escape_attrib = _escape_attrib
Thus, we have provided the “correct” incorrect processing of our XML file.
Since Python 2.4 doesn’t have the OrderedDict class on XenServer, we’ll take it with us entirely.
For the rest, and in general - the usual algorithms.
I hope this little utility will find you use. Fortunately, it can handle not only state.db, even though it is sharpened.
Not recommended for production servers.