Oh noes! I hate to make trouble for such an otherwise very nice pull-request :(  I see NO problems anywhere else!

This is lesson I have learned with much struggle, so I will pass it on to you:

Unittest cannot rely on external state or any uncontrolled input conditions.  If it does, then it cannot truly be testing the code in question (NetworkXML in this case), it will have influence from the other state/input.

With this ``NetworkXML.new_from_net_dumpxml()`` call, there are two uncontrolled items:

*  virsh command has many many hooks into current system, and system state.  This unittest is testing code that will call virsh, and for example, virsh may not even be installed on system.

*  As you check for below, sometimes the "default" network may not be defined.  However, worse than that, if it is defined, it is still not possible to 100% predict it will be in correct state for unittest to check.

There are several ways to address this, but the "easy" way (not really, it's still messy and hard) is to override the virsh class so that it never calls the real virsh command.  Instead, you write static methods that return static data to fake what real virsh command output/result would be.  This is one of the reasons we have the ``virsh_instance`` parameter to all libvirt_xml classes, as you will see below.

Take a look at ``libvirt_storage_unittest.py``, in class ``PoolTestBase``.  Scroll down and read what ``setUp()`` method does.  It makes all calls used in unittest always return predictable, static data, and never call real virsh command.  As a check, it even puts ``bogusVirshFailureException`` as all other virsh methods to make sure no call is left uncovered.  Finally, each unittest will pass this fake/bogous virsh instance into all LibvirtXMLBase subclasses for testing.  In this way also, result of unittest can be confirmed easily, because source of data is static.