- Devel - libvirt List Archives

[libvirt] [PATCH] Fix crash in remoteDispatchDomainMemoryStats (CVE-2013-4296)
by Eric Blake 19 Sep '13

19 Sep '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The 'stats' variable was not initialized to NULL, so if some early validation of the RPC call fails, it is possible to jump to the 'cleanup' label and VIR_FREE an uninitialized pointer. This is a security flaw, since the API can be called from a readonly connection which can trigger the validation checks. This was introduced in release v0.9.1 onwards by commit 158ba8730e44b7dd07a21ab90499996c5dec080a Author: Daniel P. Berrange <berrange(a)redhat.com> Date: Wed Apr 13 16:21:35 2011 +0100 Merge all returns paths from dispatcher into single path Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- Approved on the security list, and pushing on Daniel's behalf. I'm now working on backporting this to the various v*-maint branches. daemon/remote.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemon/remote.c b/daemon/remote.c index 6b082cf..3ac528c 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -1146,7 +1146,7 @@ remoteDispatchDomainMemoryStats(virNetServerPtr server ATTRIBUTE_UNUSED, remote_domain_memory_stats_ret *ret) { virDomainPtr dom = NULL; - struct _virDomainMemoryStat *stats; + struct _virDomainMemoryStat *stats = NULL; int nr_stats; size_t i; int rv = -1; -- 1.8.3.1

1 0

[libvirt] [PATCH 0/8] Normalization API
by Michal Privoznik 19 Sep '13

19 Sep '13

A while ago I've invented this vshCompleteXMLFromDomain() function to increase device-detach intelligence. Basically, it took user's XML and tried to find matching device in domain's XML. However, it was kind of buggy - finding the matching device uses string comparison. This works on text values. It doesn't on integer ones (who would expect that). So prior the lookup process, we need to normalize the integer values (and whole XML). However, this can't be done on the client side, since he has no knowledge which values are integer and which are not. Therefore we need a new API. Michal Privoznik (8): domain_conf: Introduce virDomainDeviceDefFormat Introduce new virDomainNormalizeXML API remote_driver: Implement virDomainNormalizeXML virsh: Expose virDomainNormalizeXML qemu: Implement vimDomainNormalizeXML domain_conf: Move MAC generation to post parse callback virDomainDeviceDefParse: Make PostParse callback call optional virsh: Resurrect vshCompleteXMLFromDomain daemon/remote.c | 50 ++++++++ include/libvirt/libvirt.h.in | 5 + python/generator.py | 1 + python/libvirt-override-api.xml | 7 ++ python/libvirt-override.c | 30 +++++ src/conf/domain_conf.c | 180 ++++++++++++++++------------- src/conf/domain_conf.h | 7 +- src/driver.h | 7 ++ src/libvirt.c | 51 ++++++++ src/libvirt_private.syms | 1 + src/libvirt_public.syms | 5 + src/libxl/libxl_driver.c | 12 +- src/lxc/lxc_driver.c | 6 +- src/openvz/openvz_conf.c | 1 + src/openvz/openvz_driver.c | 12 +- src/phyp/phyp_driver.c | 2 +- src/qemu/qemu_command.c | 7 +- src/qemu/qemu_driver.c | 51 +++++++- src/remote/remote_driver.c | 40 +++++++ src/remote/remote_protocol.x | 20 +++- src/uml/uml_driver.c | 4 +- src/vbox/vbox_tmpl.c | 5 +- src/vmx/vmx.c | 2 + src/xen/xend_internal.c | 6 +- src/xen/xm_internal.c | 8 +- src/xenapi/xenapi_driver.c | 1 + src/xenxs/xen_sxpr.c | 1 + src/xenxs/xen_xm.c | 1 + tests/openvzutilstest.c | 1 - tests/qemuhotplugtest.c | 3 +- tools/virsh-domain.c | 249 +++++++++++++++++++++++++++++++++++++++- tools/virsh.pod | 8 ++ 32 files changed, 666 insertions(+), 118 deletions(-) -- 1.8.1.5

4 21

[libvirt] [PATCH] doc: fix XML for the RNG device example
by Giuseppe Scrivano 19 Sep '13

19 Sep '13

Add a missing '/' to close the "source" element. Signed-off-by: Giuseppe Scrivano <gscrivan(a)redhat.com> --- A minor detail that I have noticed while I copy-pasting the example. docs/formatdomain.html.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index a927643..3689399 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -4903,8 +4903,8 @@ qemu-kvm -net nic,model=? /dev/null <backend model='random'>/dev/random</backend>  <backend model='egd' type='udp'> - <source mode='bind' service='1234'> - <source mode='connect' host='1.2.3.4' service='1234'> + <source mode='bind' service='1234'/> + <source mode='connect' host='1.2.3.4' service='1234'/> </backend> </rng> </devices> -- 1.8.3.1

2 1

[libvirt] Integrating LiSA into libvirt
by Andreea Hodea 19 Sep '13

19 Sep '13

My name is Andreea and I am a member of LiSA team. LiSA stands for Linux Switching Appliance and offers a software switch that switches packets at Layer 2 and Layer 3. It is an open source project under development, you can find more about it from lisa.mindbit.ro or from https://github.com/lisa-project/. One of the development directions of LiSA is to integrate it into libvirt. First I'll state the motivation for such an integration and then I will describe a use case. The main reasons for extending libvirt network component with LiSA are related to the fact that different hypervisors offer different switching engines with different capabilities. By integrating LiSA into libvirt, the virtual machines would connect to LiSA switch ports as they were linked through a physical switch. Hence, with LiSA, the switching engine would offer the same switching capabilities independent of hypervisor. Moreover, if I understand correctly, in libvirt switching configurations are possible either through a set of commands in virsh or directly within a XML file. One of LiSA components is swcli that is a CLI for configuring and retrieving configurations of the software switch. Through swcli, the switching configurations (including VLANs, trunk or access mode interfaces etc.) are made through a CISCO-IOS like set of commands. I think this is a nice-to-have because it would separate complex network configurations from NIC configuration. That is, through libvirt the machines would just connect to the switch and other switching configurations, simple or complex, would be made from swcli. In other words, the XML file would remain simple and readable while the user would still be able to make switching specific configurations. In conclusion, LiSA and libvirt would make a great team for building a complex networking model, without complicating the setup of a virtual network. Scenario of where LiSA fits into libvirt =========================== I thought at the following scenario: two virtual machines linked together through a LiSA switch, i.e. the LiSA switch being the physical machine running LiSA. We, LiSA team, started by studying the virt-manager interface and figured out that an entry in the "Source device" drop down list when configuring a domain NIC should suffice our goal for the moment. When applying these changes, the XML configuration file should contain an interface tag of type "lisa-switch" or something similar. Therefore, a patch to libvirt for integrating LiSA would contain: - the implementation of two functions - virNetDevLisaAddPort - virNetDevLisaRemovePort - and a new interface type (XML level) for network configuration. I would like to have your feedback on the ideas above. Thanks, Andreea

4 4

[libvirt] [PATCH 1/2] daemon: Fix 'caert.pem' typo in privileged help output
by Christophe Fergeau 18 Sep '13

18 Sep '13

The help message indicates that the CA certificate is $sysconfdir/pki/CA/caert.pem while the actual path is $sysconfdir/pki/CA/cacert.pem This commit also fixes all translations files (through sed -i) to avoid trivial fuzzy translations. Signed-off-by: Christophe Fergeau <cfergeau(a)redhat.com> --- daemon/libvirtd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index c9cd1a1..87d42b2 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -1063,7 +1063,7 @@ daemonUsage(const char *argv0, bool privileged) " %s/run/libvirt/libvirt-sock-ro\n" "\n" " TLS:\n" - " CA certificate: %s/pki/CA/caert.pem\n" + " CA certificate: %s/pki/CA/cacert.pem\n" " Server certificate: %s/pki/libvirt/servercert.pem\n" " Server private key: %s/pki/libvirt/private/serverkey.pem\n" "\n" -- 1.8.3.1

3 5

[libvirt] Operation not permitted when start vm
by yue 18 Sep '13

18 Sep '13

hi,all please look at the error. env: libvirt-0.10.2-18.el6_4.5.x86_64 2.6.32-358.6.2.el6.x86_64 centos6.4 Thread-6291::ERROR::2013-09-18 12:44:21,205::vm::683::vm.Vm::(_startUnderlyingVm) vmId=`24f7e975-9aa5-4a14-b0f0-590add14c8b5`::The vm start process failed Traceback (most recent call last): File "/us r/share/vdsm/vm.py", line 645, in _startUnderlyingVm self._run() File "/usr/share/vdsm/libvirtvm.py", line 1529, in _run self._connection.createXML(domxml, flags), File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 83, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2645, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error Process exited while reading console log output: char device redirected to /dev/pts/4 qemu-kvm: -drive file=/rhev/data-center/7828f2ae-955e-4e4b-a4bb-43807629dc52/d028d521-d4a9-4dd7-a0fe-3e9b60e7c4e4/images/ac025dc1-4e25-4b71-8c56-88dcb61b9f09/cae1bb2d-0529-4287-95a3-13dcb14f082f,if=none,id=drive-ide0-0-0,format=qcow2,serial=ac025dc1-4e25-4b71-8c56-88dcb61b9f09,cache=none,werror=stop,rerror=stop,aio=n ative: could not open disk image /rhev/data-center/7828f2ae-955e-4e4b-a4bb-43807629dc52/d028d521-d4a9-4dd7-a0fe-3e9b60e7c4e4/images/ac025dc1-4e25-4b71-8c56-88dcb61b9f09/cae1bb2d-0529-4287-95a3-13dcb14f082f: Operation not permitted

2 1

[libvirt] Doc v2: How to use NPIV in libvirt
by Osier Yang 18 Sep '13

18 Sep '13

Thanks for John Ferlan's lots of internal feedbacks, I believe it's more readable, and better orgnized now. Should we create a page for it under http://libvirt.org/deployment.html or add it in WIKI? ========================================== NPIV in libvirt NPIV (N_Port ID Virtualization) is a Fibre Channel technology to share a single physical Fibre Channel HBA with multiple virtual ports. Henceforth known as a "virtual port" or "virtual Host Bus Adapter" (vHBA), each virtual port is identified by its own WWPN (Word Wide Port Name) and WWNN (Word Wide Node Name). In the virtualization world the vHBA controls the LUNs for virtual machines. The libvirt implementation provides flexibility to configure the LUN's either directly to the virtual machine or as part of a storage pool which then can be configured for use on a virtual machine. NPIV support in libvirt was first added to libvirt 0.6.5; however, the following sections will primarily describe NPIV functionality as of the current libvirt release, 1.1.2. There will be a troubleshooting and prior version considerations section to describe some historical differences. 1) Discovery Discovery of HBA(s) capable of NPIV is provided through the virsh command 'virsh nodedev-list --cap vports'. If no HBA is returned, then the host configuration should be checked. The XML output from the command "virsh nodedev-dumpxml" will list fields <name>, <wwnn>, and <wwpn> to be used in order to create a vHBA. Take care to also note the <max_vports> value as this lets you know if the HBA is going to exceed the maximum vHBA supported. The following output indicates a host that has two HBAs to support vHBA and the layout of a HBA's XML: # virsh nodedev-list --cap vports scsi_host4 scsi_host5 # virsh nodedev-dumpxml scsi_host5 <device> <name>scsi_host5</name> <parent>pci_0000_04_00_1</parent> <capability type='scsi_host'> <host>5</host> <capability type='fc_host'> <wwnn>2001001b32a9da4e</wwnn> <wwpn>2101001b32a9da4e</wwpn> <fabric_wwn>2001000dec9877c1</fabric_wwn> </capability> <capability type='vport_ops'> <max_vports>164</max_vports> <vports>5</vports> </capability> </capability> </device> The "max_vports" value indicates there are a possible of 164 vports available for use in the HBA configuration. The "vports" value indicates the number of vports currently being used. Support for detection of HBA's capable of NPIV support prior to libvirt 1.0.4 is described in the "Troubleshooting" section. 2) Creation of a vHBA using the node device driver In order to create a vHBA using the node device driver, select an HBA with available "vport" space, use the HBA "<name>" field as the "<parent>" field in the following XML: <device> <parent>scsi_host5</parent> <capability type='scsi_host'> <capability type='fc_host'> </capability> </capability> </device> Then create the vHBA with the command "virsh nodedev-create" (assuming above XML file is named "vhba.xml"): # virsh nodedev-create vhba.xml Node device scsi_host6 created from vhba.xml NOTE: If you specify "name" for the vHBA, then it will be ignored. The kernel will automatically pick the next SCSI host name in sequence not already used. The "wwpn" and "wwnn" values will be automatically generated by libvirt. In order to see the generated vHBA XML, use the command "virsh nodedev-dumpxml" as follows: # virsh nodedev-dumpxml scsi_host6 <device> <name>scsi_host6</name> <parent>scsi_host5</parent> <capability type='scsi_host'> <capability type='fc_host'> <wwnn>2001001b32a9da5e</wwnn> <wwpn>2101001b32a9da5e</wwpn> </capability> </capability> </device> This vHBA will only be defined as long the host is not rebooted. In order to create a persistent vHBA, one must use a libvirt storage pool (see next section). 3) Creation of vHBA by the storage pool By design, vHBAs managed by the node device driver are transient across host reboots. It is recommended to define a libvirt storage pool based on the vHBA in order to preserve the vHBA configuration. Using a storage pool has two primary advantage, first the libvirt code will find the LUN's path via simple virsh command output and second migration of virtual machine's requires only defining and starting a storage pool with the same vHBA name on the target machine if you use the LUN with libvirt storage pool and volume name in virtual machine config (see section 5). In order to create a persistent vHBA configuration create a libvirt 'scsi' storage pool using the XML as follows: <pool type='scsi'> <name>poolvhba0</name> <source> <adapter type='fc_host' wwnn='20000000c9831b4b' wwpn='10000000c9831b4b'/> </source> <target> <path>/dev/disk/by-path</path> <permissions> <mode>0700</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool> You must use the "type='scsi'" for the pool; The source adapter type must be "fc_host". Attributes "wwnn" and "wwpn" are provided as the unique identifier for the vHBA to be created. There is an optional attribute "parent" for source the adapter. It indicates the name of the HBA which you want to use to create the vHBA. Its value should be consistent with what node device driver dumps (e.g. scsi_host5). If it's not specified, libvirt will pick the first HBA capable of NPIV that has not exceeded the maximum vports it supports. NOTE: You can also create a scsi pool with source adapter type "fc_host" for a HBA, and in that case the attribute "parent" is not necessary. If you prefer to choose which parent HBA to use for your vHBA, then you must provide the parent, wwnn, and wwpn in the source adapter XML as follows: <source> <adapter type='fc_host' parent='scsi_host5' wwnn='20000000c9831b4b' wwpn='10000000c9831b4b'/> </source> To define the persistent pool (assuming above XML is named as poolvhba0.xml): # virsh pool-define poolvhba0.xml NOTE: One must use pool-define to define the pool as persistent, since a pool created by pool-create is transient and it will disappear after a system reboot or a libvirtd restart. To start the pool: # virsh pool-start poolvhba0 To destroy the pool: # virsh pool-destroy poolvhba0 When starting the pool, libvirt will check if the vHBA with same "wwpn:wwpn" already exists. If it does not exist, a new vHBA with the provided "wwpn:wwnn" will be created. Correspondingly，when destroying the pool the vHBA is destroyed too. Finally, in order to ensure that subsequent reboots of your host will automatically define vHBA's for use in virtual machines, one must set the storage pool autostart feature as follows (assuming the name of the created pool was "poolvhba0"): # virsh pool-autostart poolvhba0 4) Finding LUNs on your vHBA 4.1) Utilizing LUN's from a vHBA created by the storage pool Assuming that a storage pool was created for a vHBA, use the command "virsh vol-list" command in order to generate a list of available LUN's on the vHBA, as follows: # virsh vol-list poolvhba0 --details Name Path --------------------------------------------------------------------- unit:0:2:0 /dev/disk/by-path/pci-0000:04:00.1-fc-0x203500a0b85ad1d7-lun-0 block The list of LUN names displayed will be available for use as disk volumes in virtual machine configurations. 4.2) Utilizing LUN's from a vHBA created using the node device driver Finding an available LUN from a vHBA created using the node device driver can be achieved either via use of the "virsh nodedev-list" command or through manual searching of the hosts system file system. Use the "virsh nodedev-list --tree | more" and find the parent HBA to which the vHBA was configured. The following example lists the pertinent part of the tree for the example HBA "scsi_host5": +- scsi_host5 | +- scsi_host7 +- scsi_target5_0_0 | | | +- scsi_5_0_0_0 | +- scsi_target5_0_1 | | | +- scsi_5_0_1_0 | +- scsi_target5_0_2 | | | +- scsi_5_0_2_0 | | | +- block_sdb_3600a0b80005adb0b0000ab2d4cae9254 | +- scsi_target5_0_3 | +- scsi_5_0_3_0 The "block_" indicates it's a block device, the "sdb_" is a convention to signify the the short device path of "/dev/sdb", and the short device path or the number can be used to search the "/dev/disk/by-{id,path,uuid,label}/" name space for the specific LUN by name, for example: # ls /dev/disk/by-id/ | grep 3600a0b80005adb0b0000ab2d4cae9254 scsi-3600a0b80005adb0b0000ab2d4cae9254 # ls /dev/disk/by-path/ -l | grep sdb lrwxrwxrwx. 1 root root 9 Sep 16 05:58 pci-0000:04:00.1-fc-0x203500a0b85ad1d7-lun-0 -> ../../sdb As an option to using "virsh nodedev-list", it is possible to manually iterate through the "/sys/bus/scsi/device" and "/dev/disk/by-path" directory trees in order to find a LUN using the following steps: 1. Iterate over all the directories beginning with the SCSI host number of the vHBA under the "/sys/bus/scsi/devices" tree. For example, if the SCSI host number is 6, the command would be: # ls /sys/bus/scsi/devices/6:* -d /sys/bus/scsi/devices/6:0:0:0 /sys/bus/scsi/devices/6:0:1:0 /sys/bus/scsi/devices/6:0:2:0 /sys/bus/scsi/devices/6:0:3:0 2. List the "block" names of all the entries belongs to the SCSI host as follows: # ls /sys/bus/scsi/devices/6:*/block/ /sys/bus/scsi/devices/6:0:2:0/block/: sdc /sys/bus/scsi/devices/6:0:3:0/block/: sdd This indicates that "scsi_host6" has two LUNs, one is attached to "6:0:2:0", with the short device name "sdc", and the other is attached to "6:0:3:0", with the short device name "sdd". 3. Determine the stable path to the LUN. Unfortunately a device name such as "sdc" is not stable enough for use by libvirt. In order to get the stable path, use the "ls -l /dev/disk/by-path" and look for the "sdc" path: # ls -l /dev/disk/by-path/ | grep sdc lrwxrwxrwx. 1 root root 9 Sep 10 22:28 pci-0000:08:00.1-fc-0x205800a4085a3127-lun-0 -> ../../sdc Thus "/dev/disk/by-path/pci-0000:08:00.1-fc-0x205800a4085a3127-lun-0" is the stable path of the LUN attached to address "6:0:2:0" and will be used in virtual machine configurations. 5) Virtual machine configuration change to use vHBA LUN Adding the vHBA LUN to the virtual machine configuration is done via an XML modification to the virtual machine. 5.1) Using a LUN from a vHBA created by the storage pool Adding the vHBA LUN to the virtual machine is handled via XML to create a disk volume on the virtual machine with the following example XML: <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='poolvhba0' volume='unit:0:2:0'/> <target dev='hda' bus='ide'/> </disk> In particular note the usage of the "<source>" directive with the "pool" and "volume" attributes listing the storage pool and the short volume name. 5.2) Using a LUN from a vHBA created using the node device driver Configuring a vHBA on the virtual machine can be done with its stable path (path of {by-id|by-path|by-uuid|by-label}). The following is an XML example of a direct LUN path: <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/disk/by-path/pci-0000\:04\:00.1-fc-0x203400a0b85ad1d7-lun-0'/> <target dev='sda' bus='scsi'/> </disk> NOTE: The use of "device='disk'" and the long "<source>" device name. The example uses the "by-path" option. The backslashes prior to the colons are required, since colons can be considered as delimiters. 5.3) To configure the LUN as a pass-through device, use the following XML examples. For a vHBA created using the node device driver: <disk type='volume' device='lun'> <driver name='qemu' type='raw'/> <source dev='/dev/disk/by-path/pci-0000\:04\:00.1-fc-0x203400a0b85ad1d7-lun-0'/> <target dev='sda' bus='scsi'/> </disk> NOTE: The use of "device='lun'" and again the long "<source>" device name. Again, the backslashes prior to the colons are required. For a vHBA created by a storage pool: <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='poolvhba0' volume='unit:0:2:0'/> <target dev='hda' bus='ide'/> </disk> Although it is possible to use the LUN's path as the disk source for a vHBA created by the storage pool, it is recommended to use libvirt storage pool and storage volume instead. 6) Destroying a vHBA A vHBA created by the storage pool can be destroyed by the virsh command "pool-destroy", for example: # virsh pool-destroy poolvhba0 NOTE: If the storage pool is persistent, the vHBA will also be removed by libvirt when it destroys the storage pool. A vHBA created using the node device driver can be destroyed by the command "virsh nodedev-destroy", for example (assuming that scsi_host6 was created as shown earlier): # virsh nodedev-destroy scsi_host6 Destroying a vHBA removes it just as a reboot would do since the node device driver does not support persistent configurations. 7) Troubleshooting 7.1) Discovery of HBA capable of NPIV prior to 1.0.4 Prior to libvirt 1.0.4, discovery of HBAs capable of NPIV requires checking each of the HBAs on the host for the capability flag "vport_ops", as follows: First you need to find out all the HBA by capability flag "scsi_host": # virsh nodedev-list --cap scsi_host scsi_host0 scsi_host1 scsi_host2 scsi_host3 scsi_host4 scsi_host5 Now check each HBA to find one with the "vport_ops" capability, either one at a time as follows: # virsh nodedev-dumpxml scsi_host3 <device> <name>scsi_host3</name> <parent>pci_0000_00_08_0</parent> <capability type='scsi_host'> <host>3</host> </capability> </device> That says "scsi_host3" doesn't support vHBA # virsh nodedev-dumpxml scsi_host5 <device> <name>scsi_host5</name> <parent>pci_0000_04_00_1</parent> <capability type='scsi_host'> <host>5</host> <capability type='fc_host'> <wwnn>2001001b32a9da4e</wwnn> <wwpn>2101001b32a9da4e</wwpn> <fabric_wwn>2001000dec9877c1</fabric_wwn> </capability> <capability type='vport_ops' /> </capability> </device> But "scsi_host5" supports it. NOTE: In addition to libvirt 1.0.4 automating the lookup of HBA's capable of supporting a vHBA configuration, the XML tags "max_vports" and "vports" will describe the maximum vports allowed and the current vports in use. As an alternative and smarter way, you can avoid above cumbersome steps by simple script like: for i in $(virsh nodedev-list --cap scsi_host); do if virsh nodedev-dumpxml $i | grep vport_ops > /dev/null; then echo $i; fi done NOTE: It is possible that node device is named "pci_10df_fe00_scsi_host_0". This is because libvirt supports two backends for the node device driver ("udev" and "HAL"), but they lead to completely different naming styles. The udev backend is preferred over the HAL backend since HAL support is in maintenance mode. The udev backend is more common; however, if your destribution packager built the libvirt binaries without the udev backend, then the more complicated names such as "pci_10df_fe00_scsi_host_0" must be used. 7.2) Creation of a vHBA using the node device driver prior to 0.9.10 For libvirt prior to 0.9.10, you will need to specify the "wwnn" and "wwpn" manually when creating a vHBA, example XML as follows: <device> <name>scsi_host6</name> <parent>scsi_host5</parent> <capability type='scsi_host'> <capability type='fc_host'> <wwnn>2001001b32a9da5e</wwnn> <wwpn>2101001b32a9da5e</wwpn> </capability> </capability> </device> 7.3) Creation of storage pool based on vHBA prior to 1.0.5 Prior to libvirt 1.0.5, one can define a "scsi" type pool based on a vHBA by it's SCSI host name (e.g. "host5" in XML below), using an example XML as follows: <pool type='scsi'> <name>poolhba0</name> <uuid>e9392370-2917-565e-692b-d057f46512d6</uuid> <capacity unit='bytes'>0</capacity> <allocation unit='bytes'>0</allocation> <available unit='bytes'>0</available> <source> <adapter name='host0'/> </source> <target> <path>/dev/disk/by-path</path> <permissions> <mode>0700</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool> There are two disadvantage of using the SCSI host name as the source adapter. First the SCSI host number is not stable, thus it may cause trouble for your storage pool after a system reboot. Second, the adapter name (e.g. "host5") is not consistent with node device name (e.g. "scsi_host5"). Moreover, using the SCSI host name as the source adapter doesn't allow you to create a vHBA. NOTE: Since 1.0.5, the source adapter name was changed to be consistent with node device name, thus the second disadvantage is destroyed. Regards, Osier

1 1

[libvirt] [PATCH 0/3] Libvirt Wireshark dissector
by Yuto KAWAMURA(kawamuray) 18 Sep '13

18 Sep '13

From: "Yuto KAWAMURA(kawamuray)" <kawamuray.dadada(a)gmail.com> Introduce Wireshark dissector plugin which adds support to Wireshark for dissecting libvirt RPC protocol. This feature was presented by Michal Privoznik year before last[1]. But it did only support dissecting packet headers. This time I enhanced that dissector to support dissecting packet payload. Furthermore, I provide code generator of dissector. So you can get fresh build of dissector from libvirt RPC specification file at any version you like. [1] http://www.redhat.com/archives/libvir-list/2011-October/msg00301.html Yuto KAWAMURA(kawamuray) (3): Exclude files in VC_LIST_ALWAYS_EXCLUDE_REGEX from bracket-spacing-check Introduce Libvirt Wireshark dissector Add sample output of Wireshark dissector Makefile.am | 3 +- cfg.mk | 10 +- configure.ac | 69 +- devtools/wireshark-dissector/Makefile.am | 28 + devtools/wireshark-dissector/README.md | 25 + .../samples/libvirt-sample.pdml | 7970 ++++++++++++++++++++ devtools/wireshark-dissector/src/.gitignore | 2 + devtools/wireshark-dissector/src/Makefile.am | 31 + devtools/wireshark-dissector/src/moduleinfo.h | 36 + devtools/wireshark-dissector/src/packet-libvirt.c | 512 ++ devtools/wireshark-dissector/src/packet-libvirt.h | 127 + devtools/wireshark-dissector/src/plugin.c | 27 + devtools/wireshark-dissector/util/genxdrstub.pl | 1009 +++ 13 files changed, 9842 insertions(+), 7 deletions(-) create mode 100644 devtools/wireshark-dissector/Makefile.am create mode 100644 devtools/wireshark-dissector/README.md create mode 100644 devtools/wireshark-dissector/samples/libvirt-sample.pdml create mode 100644 devtools/wireshark-dissector/src/.gitignore create mode 100644 devtools/wireshark-dissector/src/Makefile.am create mode 100644 devtools/wireshark-dissector/src/moduleinfo.h create mode 100644 devtools/wireshark-dissector/src/packet-libvirt.c create mode 100644 devtools/wireshark-dissector/src/packet-libvirt.h create mode 100644 devtools/wireshark-dissector/src/plugin.c create mode 100755 devtools/wireshark-dissector/util/genxdrstub.pl -- 1.8.1.5

5 14

[libvirt] [PATCH v3 0/7] add new API virConnectGetCPUModelNames
by Giuseppe Scrivano 18 Sep '13

18 Sep '13

This series adds a new API "virConnectGetCPUModelNames" that allows to retrieve the list of CPU models known by the hypervisor for a specific architecture. This new function is mainly needed by virt-manager to not read directly the cpu_map.xml file (it could also be different when accessing a remote daemon). I have amended all the comments reported for v2. *v3 main changes - virConnectGetCPUModelNames returns the number of models instead of 0 on success. - Use VIR_INSERT_ELEMENT instead of VIR_EXPAND_N. - Fix a potential memory leak in the python bindings. - Move virsh changes to a separate commit. - Remove API documentation from libvirt.h. *v2 main changes - set a hard limit for the number of CPU models that is possible to fetch from a remote server. - Use VIR_EXPAND_N instead of VIR_REALLOC_N. - s|1.1.2|1.1.3| Giuseppe Scrivano (7): libvirt: add new public API virConnectGetCPUModelNames cpu: add function to get the models for an arch virConnectGetCPUModelNames: implement the remote protocol virConnectGetCPUModelNames: add the support for qemu virConnectGetCPUModelNames: add the support for the test protocol virsh: add function to get the CPU models for an arch python: add bindings for virConnectGetCPUModelNames daemon/remote.c | 43 +++++++++++++++++++++++++++++++ include/libvirt/libvirt.h.in | 4 +++ python/generator.py | 1 + python/libvirt-override-api.xml | 7 +++++ python/libvirt-override.c | 52 +++++++++++++++++++++++++++++++++++++ python/libvirt-override.py | 11 ++++++++ src/cpu/cpu.c | 56 ++++++++++++++++++++++++++++++++++++++++ src/cpu/cpu.h | 3 +++ src/driver.h | 7 +++++ src/libvirt.c | 46 +++++++++++++++++++++++++++++++++ src/libvirt_private.syms | 1 + src/libvirt_public.syms | 5 ++++ src/qemu/qemu_driver.c | 14 ++++++++++ src/remote/remote_driver.c | 57 +++++++++++++++++++++++++++++++++++++++++ src/remote/remote_protocol.x | 20 ++++++++++++++- src/remote_protocol-structs | 11 ++++++++ src/test/test_driver.c | 11 ++++++++ tools/virsh-host.c | 54 ++++++++++++++++++++++++++++++++++++++ tools/virsh.pod | 5 ++++ 19 files changed, 407 insertions(+), 1 deletion(-) -- 1.8.3.1

4 25

[libvirt] [PATCH] qemu: Avoid dangling job in qemuDomainSetBlockIoTune
by Jiri Denemark 18 Sep '13

18 Sep '13

virDomainSetBlockIoTuneEnsureACL was incorrectly called after we already started a job. As a result of this, the job was not cleaned up when an access driver had forbidden the action. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_driver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 0763f9b..8a302d1 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -14673,15 +14673,15 @@ qemuDomainSetBlockIoTune(virDomainPtr dom, if (!(vm = qemuDomObjFromDomain(dom))) return -1; + if (virDomainSetBlockIoTuneEnsureACL(dom->conn, vm->def, flags) < 0) + goto cleanup; + if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_MODIFY) < 0) goto cleanup; priv = vm->privateData; cfg = virQEMUDriverGetConfig(driver); - if (virDomainSetBlockIoTuneEnsureACL(dom->conn, vm->def, flags) < 0) - goto cleanup; - if (!(caps = virQEMUDriverGetCapabilities(driver, false))) goto endjob; -- 1.8.3.2

2 2