XML processing of Citrix XenServer 5.6 Free configuration directly

    While working with XenServer, you can change its configuration in various ways.
    Starting from the XenCenter graphical utility and the xe console command, ending with a direct intervention in the XML config.
    That's about the latter and I would like to talk with you.

    Not all the desired actions can be done with regular 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 API center for XenServer is xapi daemons .

    Their motility, in terms of storage configuration, is as follows:
    1. Launch XAPI
    2. Loading XML state.db into memory
    3. Operation (at this time all changes occur in memory)
    4. Stopping XAPI
    5. Writing to XML state.db

    Since XAPI cuts unauthorized changes “on the go”, it’s better to perform actions directly with the file, stopping the xapi service for this .
    But here several "BUT" come into force.
    The biggest BUT is the inconvenience of processing a file using vi and other editors.
    BUT secondary, but no less problematic: For XenServer, the order of the attributes in XML is critical. Therefore, standard parsing methods disappear.

    For convenient search and change of parameters in this file, I created the utility xmlsh.py

    Using 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. A complete list is obtained with the help command.

    I hope XenServer admins like this utility.

    Well, now let's get back to “abnormal programming”.
    During the creation of the utility, I encountered a lot of "ideological" difficulties.
    And first of all, how python XML processing is implemented. 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 has a transparent parsing system, which allows you to redefine the main methods for implementing "OrderedDict" (Why? More on that later).
    Thus, I had to use both:
    minidom is used as the basis of “dynamic movement” and display of content.
    ElementTree is used only for editing and recording a file.
    All this is a necessary measure due to the dependence of XenServer on the order of attributes in the tag (which, incidentally, is non-compliance with the standard).

    Thus, to make ElementTree behave "inappropriately", the following overrides were required:

    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 remember the sequence of adding elements to the list.
    You can see the secondary change by the code below: function substitution
    and method substitution
    etree._escape_attrib = _escape_attrib
    Thus, we ensured the “correct” incorrect processing of our XML file.
    Since there is no OrderedDict class in Python 2.4 on XenServer, we will take it with us as a whole.
    Otherwise, it’s the usual algorithm.

    I hope this little utility will find you application. Fortunately, it can be processed not only by state.db, even though it is imprisoned for it.

    Not recommended for use on production servers.

    Also popular now: