[libvirt] Node devices?
After staring at the code implementing node devices in libvirt, I have decided that they're really neat, but I have no idea what they are for or how to use them. Reading the API docs and searching libvir-list didn't help much, and the user documentation (http://libvirt.org/archnode.html and http://libvirt.org/formatnode.html) is a bit, err, high-level. Can someone enlighten me? --Ed
Ed Swierk wrote:
After staring at the code implementing node devices in libvirt, I have decided that they're really neat, but I have no idea what they are for or how to use them.
Reading the API docs and searching libvir-list didn't help much, and the user documentation (http://libvirt.org/archnode.html and http://libvirt.org/formatnode.html) is a bit, err, high-level.
Can someone enlighten me?
--Ed
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 Tue, Feb 09, 2010 at 03:57:28PM -0800, Ed Swierk wrote:
After staring at the code implementing node devices in libvirt, I have decided that they're really neat, but I have no idea what they are for or how to use them.
Reading the API docs and searching libvir-list didn't help much, and the user documentation (http://libvirt.org/archnode.html and http://libvirt.org/formatnode.html) is a bit, err, high-level.
Can someone enlighten me?
Mostly what Alex already said :-) The libvirt APIs are split into several functional areas - virDomain - guest management - virInterface - host network interface configuration - virStorage - storage manangement - virNetwork - virtual networking The goal is that an app should be able to accomplish all its virtualization management tasks without needing any other remote access to the host via SSH or other systems. Many of the APIs for those areas I mention above require knowledge of what physical devices are present on the machine. For example, assigning a PCI or USB device to a guests requires that you know what PCI / USB devices the host has. Setting up a storage pool requires knowing what disks are available. Configuring network interfaces requires knowing what NICs are available, etc. So 'virNodeDev' APIs provide the missing link that lets you discover the information about a host that you need in order to use the other APIs. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Wed, Feb 10, 2010 at 1:02 AM, Daniel P. Berrange <berrange@redhat.com> wrote:
Mostly what Alex already said :-)
The libvirt APIs are split into several functional areas
- virDomain - guest management - virInterface - host network interface configuration - virStorage - storage manangement - virNetwork - virtual networking
The goal is that an app should be able to accomplish all its virtualization management tasks without needing any other remote access to the host via SSH or other systems. Many of the APIs for those areas I mention above require knowledge of what physical devices are present on the machine. For example, assigning a PCI or USB device to a guests requires that you know what PCI / USB devices the host has. Setting up a storage pool requires knowing what disks are available. Configuring network interfaces requires knowing what NICs are available, etc. So 'virNodeDev' APIs provide the missing link that lets you discover the information about a host that you need in order to use the other APIs.
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:
On Wed, Feb 10, 2010 at 1:02 AM, Daniel P. Berrange <berrange@redhat.com> wrote:
Mostly what Alex already said :-)
The libvirt APIs are split into several functional areas
- virDomain - guest management - virInterface - host network interface configuration - virStorage - storage manangement - virNetwork - virtual networking
The goal is that an app should be able to accomplish all its virtualization management tasks without needing any other remote access to the host via SSH or other systems. Many of the APIs for those areas I mention above require knowledge of what physical devices are present on the machine. For example, assigning a PCI or USB device to a guests requires that you know what PCI / USB devices the host has. Setting up a storage pool requires knowing what disks are available. Configuring network interfaces requires knowing what NICs are available, etc. So 'virNodeDev' APIs provide the missing link that lets you discover the information about a host that you need in order to use the other APIs.
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?
The nodedev-create function is currently only used to create NPIV virtual adapters. It's true in general that 'creating' a node device doesn't really make sense, since a node device is actually physical hardware, hence the very limited application ATM. Similarly nodedev-destroy destroys NPIV virtual adapters. - Cole
On 02/10/2010 07:23 PM, Ed Swierk wrote:
On Wed, Feb 10, 2010 at 1:02 AM, Daniel P. Berrange<berrange@redhat.com> wrote:
Mostly what Alex already said :-)
The libvirt APIs are split into several functional areas
- virDomain - guest management - virInterface - host network interface configuration - virStorage - storage manangement - virNetwork - virtual networking
The goal is that an app should be able to accomplish all its virtualization management tasks without needing any other remote access to the host via SSH or other systems. Many of the APIs for those areas I mention above require knowledge of what physical devices are present on the machine. For example, assigning a PCI or USB device to a guests requires that you know what PCI / USB devices the host has. Setting up a storage pool requires knowing what disks are available. Configuring network interfaces requires knowing what NICs are available, etc. So 'virNodeDev' APIs provide the missing link that lets you discover the information about a host that you need in order to use the other APIs.
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...)
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
participants (5)
-
ajia -
Cole Robinson -
Daniel P. Berrange -
Dave Allan -
Ed Swierk