Ed Swierk wrote: Hi, Ed, I am not a libvirt developer, maybe I only talk about it with you under my understand, and I hope it is helpful to you. At first, it will be better if I explain simply libvirt's goal and some basic concept: 1.The goal of libvirt: to provide a common generic and stable layer to securely manage domains on a node. 2. what is the node? A node is a single physical machine, in other words, a node is a host and a domain is an instance of an operating system(also known guest) Node devices should be some devices on the host, such as PCI device, In my opinion, you may understand its function from the use, a group virsh comand can help you, for example: [root@dhcp-66-70-173 ~]# virsh help | grep node nodeinfo node information nodedev-list enumerate devices on this host nodedev-dumpxml node device details in XML nodedev-dettach dettach node device its device driver nodedev-reattach reattach node device its device driver nodedev-reset reset node device nodedev-create create a device defined by an XML file on the node nodedev-destroy destroy a device on the node 1. display host information [root@dhcp-66-70-173 ~]# virsh nodeinfo CPU model: x86_64 CPU(s): 2 CPU frequency: 2327 MHz CPU socket(s): 1 Core(s) per socket: 2 Thread(s) per core: 1 NUMA cell(s): 1 Memory size: 2014320 kB 2. display devices on the host [root@dhcp-66-70-173 ~]# virsh nodedev-list --tree computer | +-pci_8086_10bd | | | +-net_00_1e_4f_db_02_5c | +-pci_8086_244e +-pci_8086_2914 ...... 3. display specify device xml description [root@dhcp-66-70-173 ~]# virsh nodedev-dumpxml pci_8086_10bd <device> <name>pci_8086_10bd</name> <parent>computer</parent> <capability type='pci'> <domain>0</domain> <bus>0</bus> <slot>25</slot> <function>0</function> <product id='0x10bd'>82566DM-2 Gigabit Network Connection</product> <vendor id='0x8086'>Intel Corporation</vendor> </capability> </device> 4. dettach host device its device driver [root@dhcp-66-70-173 ~]# virsh nodedev-dettach pci_8086_10bd Device pci_8086_10bd dettached in fact, the operation hide the device host driver and bind the device to pci-stub driver [root@dhcp-66-70-173 ~]# readlink /sys/bus/pci/devices/0000\:00\:19.0/driver ../../../bus/pci/drivers/pci-stub 5. in order to return the device a certain&clean status, we need to reset the device [root@dhcp-66-70-173 ~]# virsh nodedev-reset pci_8086_10bd Device pci_8086_10bd reset 6. return the device from guest to host [root@dhcp-66-70-173 ~]# virsh nodedev-reattach pci_8086_10bd Device pci_8086_10bd re-attached From step 2 to step 6, this group operations is very useful, such as we pass through a host pci device to guest. Best Regards, Alex Jia

On Wed, Feb 10, 2010 at 1:02 AM, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote: Thanks, Daniel and Alex, that helps a lot. I'm still not clear about the purpose of the node device XML format, and the nodedev-create virsh command. What does it mean to "create a device" on a node, if the node device info is gathered via udev or hal from the actual hardware? Is this to fill in gaps in udev's or hal's knowledge of the hardware? (In addition to sheer curiosity, I'm thinking about whether the node device API could be used to solve a specific issue with the current macvtap implementation, namely handling the dynamic addition and removal of the underlying network device. I want to try to understand the libvirt-y way of doing things before I go and propose something completely stupid...) --Ed

On 02/10/2010 07:23 PM, Ed Swierk wrote: The node device create and destroy operations really do create and destroy virtual "hardware", which should then be discovered through udev and become visible to libvirt like all other hardware. It's the equivalent of someone walking up to a box and hotplugging a new physical device. If the operation you're trying to implement ends with something that looks like new hardware appearing in the host OS, it's likely to be a good fit for the node device create/destroy API. I don't know a whole lot about the macvtap or macvlan stuff, but from what little I do know it looks like the kind of thing that the API was designed to handle. As Cole has pointed out the only current use for it is creating and destroying virtual HBAs using NPIV, however, it is intended to be generic enough to handle all kinds of virtual devices. Dave