On 02/10/2012 03:35 PM, Eric Blake wrote:
> On 02/10/2012 12:42 PM, Laine Stump wrote:
>> On 02/10/2012 01:45 PM, Eric Blake wrote:
>>> On 02/10/2012 05:43 AM, Székelyi Szabolcs wrote:
>>>> I've also noticed that the domain description passed to the hook script
>>>> doesn't contain the network device the host will be attached to (XPath:
>>>> /domain/devices/interface/target/@dev).
>>> This is a different question; right now it is a feature that we don't
>>> ever expose the actual network device through dumpxml to the user. But
>>> given your use case of a hook, we might have a reason to do it after
>>> all. Laine, thoughts?
>>>
>> I don't recall why I chose to not expose it in a live dumpxml. I would
>> have to take some time rewinding to remember. It could be I just didn't
>> see a need for polluting public API at the time (and it's always easier
>> to add something in later than to take it away).
> That's my recollection as well - we didn't want to expose it if we
> didn't see a use; knowing full well that we could turn it on later (but
> could not turn it off later if it was on from the get-go). Sounds like
> we're in agreement then on turning it on. Is it best to do that by
> adding a new flags bit to dumpxml?
I think if it's going to be turned on, it can just be included in any
output of live xml.
One potential problem with this is that, as it stands, someone wanting
to know, e.g., which ethernet device a guest interface is connected to
with macvtap will need to look in two places - 1) if there is no
<actual> element, then it will be in <source dev='ethX'/> under the main
interface element, but if there *is* an <actual>, then it's <source
dev='ethX'/> under <actual>. (In other words, if the original interface
type isn't 'network', then <actual> won't be filled in. The question
then is whether or not we *want* it filled in.)
An alternate implementation would be to write live XML to the public API
as if the interface config acquired from the network definition had been
hand-configured. So, for example, if the original config was:
<interface type='network'>
<mac address='52:54:00:1e:0d:8a'/>
<source network='test-direct'/>
<model type='virtio'/>
</interface>
and the current "status" xml (that libvirt stores privately) was:
<interface type='network'>
<mac address='52:54:00:1e:0d:8a'/>
<source network='test-direct'/>
<actual type='direct'>
<source dev='eth0' mode='bridge'/>
</actual>
<target dev='macvtap0'/>
<model type='virtio'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06'
function='0x0'/>
</interface>
maybe the live xml output to the public API could be:
<interface type='direct'>
<mac address='52:54:00:1e:0d:8a'/>
<source dev='eth0' mode='bridge'/>
<target dev='macvtap0'/>
<model type='virtio'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06'
function='0x0'/>
</interface>
(basically moving everything in <actual> up to <interface>). This would
make it easier for people trying to do report status kinds of things,
and the loss of original config data wouldn't be a problem here, but I
don't know if that would be an acceptable practice.
