October 2011 - Devel - libvirt List Archives

Re: [libvirt] [libvirt PATCHv4 1/2] add DHCP snooping
by Stefan Berger 28 Oct '11

28 Oct '11

David Stevens/Beaverton/IBM wrote on 10/27/2011 02:51:18 PM: > Stefan Berger <stefanb(a)linux.vnet.ibm.com> wrote on 10/25/2011 05:50:09 AM: > > > The below algorithm also seems to assume that the VM does not send > > 802.1Q (VLAN) headers. I remember having had problems when trying to > > receive 802.1Q headers when the VM's interface is on a bridge and the > > remote traffic comes through the network. I wonder whether it generally > > doesn't work. I think at least in the code you should look at the > > header, check for ETHERTYPE_IPv4 and then use eh_data[0], otherwise > > either discard it or if ETHERTYPE_VLAN (0x8100) is used read the > > encapsulated protocol ID and make sure ETHERTYPE_IPv4 is found there and > > then use eh_data[4] for further processing. > > Stefan, > I added code similar to what you had, but when trying to test it, > I realized that this cannot work with the existing filters. It appears > to me that if a VLAN header is present, that packet won't match any of > the protocols supported and will be dropped (ETHERTYPE_VLAN won't match > IPv4, ARP, RARP, etc). If so, then decoding a VLAN DHCP ACK does no good So that sounds like an ebtables problem then not being able to handle ethernet packets with a VLAN header. > because the VM will never see it, and the rules will never even check a > source IP address for a packet that ebtables won't match as an IP packet. > Right? You're right. Implementation-wise I still think you should look at the Ethernet header and check for ETHERTYPE_IPV4 to get the offset for the payload and for now skip all other types of packets. One could setup VMs on the same host, have their interfaces connected to a bridge and have them talk via VLAN and possibly provoke errors in the packet parser(s). The conclusion is that VMs sending VLAN traffic themselves is not supported. If a bridge has a VLAN interface of the host for sending/receiving VLAN traffic to/from the physical network, the filtering still works as expected. > > I saw later your post for VLAN filtering. I haven't played with > vlans much, and especially not with ebtables filtering of vlans. If > we cannot apply the higher-layer protocol rules without making a > complete copy of all of them for VLANs, then I'm not sure I see the > point in having address learning decode VLAN headers. That's fine then. > For the "no spoofing" case, allowing all VLAN packets is clearly > not right, so it appears to me that the current nwfilters simply do > not support the presence of VLANs. Yes, VLAN traffic directly from the VM is not supported with the example filters and has limitations when trying to evaluate the packets. The VLAN support I posted can serve other purposes. > I can leave the current (untested) address matching checks in. It > doesn't hurt the non-VLAN case, if you see some way of adding full VLAN > no-spoofing support in the future. But unless I'm missing something, it > doesn't look to me like the VLAN case works at all now and not supporting > that in DHCP snooping is not a new problem. Agreed. Stefan > > +-DLS

1 0

[libvirt] [libvirt PATCHv4 0/2] DHCP Snooping support for libvirt
by David L Stevens 28 Oct '11

28 Oct '11

These patches add DHCP snooping support to libvirt. The learning method for IP addresses is specified by setting the "ip_learning" variable to one of "any" [default] (existing IP learning code), "none" (static only addresses) or "dhcp" (DHCP snooping). Differences from v3: removed support for multiple IP addresses. This version, like this existing code, allows only one IP address per interface. David L Stevens (2): add DHCP snooping add leasefile support examples/xml/nwfilter/no-ip-spoofing.xml | 5 + src/Makefile.am | 2 + src/nwfilter/nwfilter_dhcpsnoop.c | 1005 ++++++++++++++++++++++++++++++ src/nwfilter/nwfilter_dhcpsnoop.h | 38 ++ src/nwfilter/nwfilter_driver.c | 5 + src/nwfilter/nwfilter_gentech_driver.c | 51 ++- 6 files changed, 1093 insertions(+), 13 deletions(-) create mode 100644 src/nwfilter/nwfilter_dhcpsnoop.c create mode 100644 src/nwfilter/nwfilter_dhcpsnoop.h -- 1.7.6.4

3 10

[libvirt] [PATCH 0/4] Make rewriting XML files more robust
by Jiri Denemark 28 Oct '11

28 Oct '11

Jiri Denemark (4): Introduce virFileSync Introduce virFileRewrite for safe file rewrite Introduce virXMLSaveFile as a wrapper for virFileRewrite Use virXMLSaveFile when writing XML config src/conf/domain_conf.c | 32 +------------------- src/conf/network_conf.c | 34 +-------------------- src/conf/nwfilter_conf.c | 68 ++---------------------------------------- src/conf/storage_conf.c | 37 ++--------------------- src/libvirt_private.syms | 3 ++ src/qemu/qemu_domain.c | 19 +----------- src/util/util.c | 4 ++- src/util/virfile.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++ src/util/virfile.h | 8 +++++ src/util/xml.c | 36 +++++++++++++++++++++++ src/util/xml.h | 5 +++ 11 files changed, 141 insertions(+), 177 deletions(-) -- 1.7.7

3 15

[libvirt] [PATCH V3 0/4] Support for multiple IP addresses using lists
by Stefan Berger 28 Oct '11

28 Oct '11

This patch series builds on the previously posted patch series https://www.redhat.com/archives/libvir-list/2011-October/msg00912.html and introduces the capability to assign a list to a variable and have multiple rules instantiated, one for each item in the list. This means, that if for example a variable like IP has been assigned a list of values IP = [1.2.3.4, 5.6.7.8, 10.0.0.1] it will instantiate 3 rules (on the ebtables/iptables level) for a single XML filtering rule. This in turn allows us to build filters that can evaluate multiple possible values per field, i.e., allow the filtering for multiple IP addresses (per interface). It would then need David Steven's patch for support of 'RETURN' (and 'CONTINUE') target(s). v3: - following Daniel Berrange's comment regarding how a list of items should be represented in the XML v2: - reimplementation of iterator - other nits Regards, Stefan

3 13

Re: [libvirt] [libvirt PATCHv4 1/2] add DHCP snooping
by Stefan Berger 28 Oct '11

28 Oct '11

David Stevens/Beaverton/IBM wrote on 10/26/2011 06:51:26 PM: > Stefan Berger <stefanb(a)linux.vnet.ibm.com> wrote on 10/26/2011 11:32:25 AM: > > > > Also, in case learning is NULL, you may need to set it to 'any' (for > > backwards-compatibility) to avoid a NULL pointer crash later on. > > I didn't try it with NULL -- if it is not set (ie, the variable is not > present at all), it defaults to "any" already. If it's set to garbage, That was not the behavior I had encountered. I forgot to put the ip_learning into the collection of variables and then learning ended up being NULL, which then crashed it. > I did have some issues with restarting libvirtd (primarily VM's exiting when > I restarted multiple times), but those were there before I applied any of > these patches; no log messages when that happened. By the way, also try the 'kill -SIGHUP `pidof libvirtd`' to have the filters rebuilt. It's similar to a restart of libvirtd. Stefan

1 0

[libvirt] [PATCH v3 00/13] Implement keepalive protocol for libvirt RPC
by Jiri Denemark 28 Oct '11

28 Oct '11

This patchset can also be found at https://gitorious.org/~jirka/libvirt/jirka-staging/commits/keepalive This allows us to detect broken connections between server and client without waiting for TCP timeout and dead deamon/client. By default a connection is considered broken after about 30 seconds of no messages received from remote party. After that period, the connection is automatically closed. The main reason for implementing this is that peer-to-peer migration can now be canceled when a connection between source and target breaks. Although this will really work only after qemu fixes migrate_cancel command so that it doesn't block when outgoing TCP buffers are full. Version 3 addresses comments from Daniel (more details can be found in each patch) except for the default settings on server side. Daniel suggested keepalive should be switched off by default, while I think it should be on if possible, but that (and if on, with what interval and count) can be discussed further since it has negligible impact on the patchset. Jiri Denemark (13): Define keepalive protocol Implement common keepalive handling Introduce virConnectSetKeepAlive virsh: Always run event loop Implement keepalive protocol in libvirt daemon Add support for non-blocking calls in client RPC Add support for async close of client RPC socket Implement keepalive protocol in remote driver Introduce virConnectIsAlive API Implement virConnectIsAlive in all drivers Add keepalive support into domain-events examples qemu: Add support for keepalive messages during p2p migration qemu: Cancel p2p migration when connection breaks .gitignore | 1 + daemon/libvirtd.aug | 5 + daemon/libvirtd.c | 15 + daemon/libvirtd.conf | 22 + daemon/libvirtd.h | 1 + daemon/remote.c | 48 +++- examples/domain-events/events-c/event-test.c | 9 +- examples/domain-events/events-python/event-test.py | 4 +- include/libvirt/libvirt.h.in | 5 + po/POTFILES.in | 1 + src/Makefile.am | 15 +- src/driver.h | 8 + src/esx/esx_driver.c | 18 + src/hyperv/hyperv_driver.c | 18 + src/libvirt.c | 90 ++++ src/libvirt_internal.h | 10 +- src/libvirt_private.syms | 2 + src/libvirt_public.syms | 2 + src/libxl/libxl_driver.c | 8 + src/lxc/lxc_driver.c | 7 + src/openvz/openvz_driver.c | 7 + src/phyp/phyp_driver.c | 18 + src/qemu/libvirtd_qemu.aug | 2 + src/qemu/qemu.conf | 19 + src/qemu/qemu_conf.c | 11 + src/qemu/qemu_conf.h | 3 + src/qemu/qemu_driver.c | 6 + src/qemu/qemu_migration.c | 43 ++- src/qemu/test_libvirtd_qemu.aug | 6 + src/remote/remote_driver.c | 70 ++++ src/remote/remote_protocol.x | 2 +- src/rpc/virkeepalive.c | 426 ++++++++++++++++++++ src/rpc/virkeepalive.h | 56 +++ src/rpc/virkeepaliveprotocol.x | 7 + src/rpc/virnetclient.c | 316 +++++++++++++--- src/rpc/virnetclient.h | 6 + src/rpc/virnetserver.c | 22 + src/rpc/virnetserver.h | 5 + src/rpc/virnetserverclient.c | 143 ++++++- src/rpc/virnetserverclient.h | 7 + src/test/test_driver.c | 6 + src/uml/uml_driver.c | 7 + src/util/event.c | 6 +- src/vbox/vbox_tmpl.c | 6 + src/vmware/vmware_driver.c | 7 + src/xen/xen_driver.c | 8 + src/xenapi/xenapi_driver.c | 12 + tools/console.c | 17 +- tools/virsh.c | 31 ++ 49 files changed, 1477 insertions(+), 87 deletions(-) create mode 100644 src/rpc/virkeepalive.c create mode 100644 src/rpc/virkeepalive.h create mode 100644 src/rpc/virkeepaliveprotocol.x -- 1.7.7

3 29

[libvirt] custom network filter
by Shahar Havivi 27 Oct '11

27 Oct '11

Hi, I am having a VDSM hook that use custom network filter: <filter name='isolatedprivatevlan-vdsm' chain='root'> <uuid>aca4bfab-432c-54ac-aa62-b76c328ebbf2</uuid> <filterref filter='clean-traffic'/> <rule action='drop' direction='out' priority='500'> <mac match='no' dstmacaddr='$GATEWAY_MAC'/> </rule> </filter> the filter file name is isolatedprivatevlan-vdsm.xml, and installed in: /etc/libvirt/nwfilter/isolatedprivatevlan-vdsm.xml when I try to use it in libvirt domain xml: <interface> ... <filterref filter="isolatedprivatevlan-rhevm"> <parameter name="GATEWAY_MAC" value="aa:aa:aa:aa:aa:aa"/> </filterref> </interface> I am getting the following error: Network filter not found: Could not find filter 'isolatedprivatevlan-rhevm' The hook was running but not at my current version: libvirt-0.9.4-17.el6.x86_64 I try to install nwfilter-define via virsh and the list command, nwfilter-list - I can see the custom filter but again the same error. any ideas? Thank you, Shahar Havivi.

2 1

[libvirt] QEMU 1.0 test day - November 7th
by Paolo Bonzini 27 Oct '11

27 Oct '11

Hi all, QEMU 1.0 test day will be held on November 7th. Any kind of testing that you can contribute will be appreciated---including testing your favorite hypervisor, desktop virtualization or management stack together with the new release. You are also welcome to add testing hints at http://wiki.qemu.org/Planning/1.0/Testing for people to try out. People participating in the test day should also: - hang out if possible on the QEMU IRC channel (irc.oftc.org, #qemu) - record the results of their testing at http://wiki.qemu.org/Planning/1.0/Testing Regards, Paolo

1 0

[libvirt] changes to domain XML for SCSI support
by Paolo Bonzini 27 Oct '11

27 Oct '11

Hi all, let's kick off the discussion on what changes are needed in domain XML for more complete SCSI support. There are three relevant topics: 1) providing channel/target/lun addresses for SCSI disks; 2) supporting LUN passthrough; 3) supporting SCSI host passthrough. A fourth topic is supporting NPIV. It is a special case of SCSI host passthrough, and it is important that any extension to the domain XML can cover it. Enhanced addressing for SCSI devices ==================================== This is the simplest part. The proposal is to add a new address type <address type='scsi' host='...' bus='...' target='...' lun='...'/> where host selects the qdev parent device, while channel/target/lun are passed as qdev properties (the QEMU names are respectively channel, scsi-id, lun). Libvirt should check for QEMU 1.0 and, for older versions, only allow channel=lun=0 and 0<=target<=7. LUN passthrough =============== A SCSI block device from the host can be attached to a domain in two ways: as an emulated LUN with SCSI commands implemented within QEMU, or by passing SCSI commands down to the block device. The former is handled by the existing <disk type='disk'> and <disk type='cdrom'> XML syntax. The latter is not yet supported. On the QEMU side, LUN passthrough is implemented by one of the scsi-generic and scsi-block devices. Scsi-generic requires a /dev/sg device name, and can be applied to any device. scsi-block is only available in QEMU 1.0 or newer, requires a block device, can be applied only to block devices (sd/sr) and has better performance. The choice between one and the other should be as transparent as possible. Currently, using a block device as the backend for a virtio disk implements a kind of LUN passthrough, since the guest can execute There are two possible choices here: 1) add a new <hostdev> tag. <hostdev mode='subsystem' type='scsi'> <source> <address type='scsi' host='...' bus='...' target='...' lun='...'/> </source> <address type='scsi' host='...' bus='...' target='...' lun='...'/> </hostdev> Advantages: - allows using the same XML for all SCSI devices (i.e. scsi-generic vs. scsi-block is an internal detail of libvirt); Disadvantages: - does not make it clear which device is being passed through; - completely different from the syntax that virtio is using for the same purpose; perhaps virtio could be covered by <hostdev mode='subsystem' type='scsi'> <source> <address type='scsi' host='...' bus='...' target='...' lun='...'/> </source> <target dev='vda' bus='virtio'/> <address type='pci' host='...' bus='...' target='...' lun='...'/> </hostdev> - <address> specifies the address to a <capability type='scsi'> device, but the device to be passed to scsi-block is its block_sdXX_* child (aside: it would be nice if the /dev/sgNN name was placed somewhere in the nodedev XML for <capability type='scsi'> devices); - emulated and passthrough LUNs have a completely different XML; - host numbers are not stable when hotplugging. 2) add a new <drive device='lun'> attribute. <drive type='block' device='lun'> <driver name='qemu' type='raw'/> <source dev='/dev/sda'/> <target dev='sda' bus='scsi'> <address type='scsi' host='...' bus='...' target='...' lun='...'/> </drive> Advantages: - allows using the same syntax for virtio and SCSI. virtio could be changed to accept device='lun' too. - the passed-through device is immediately visible - a stable addressing is available via /dev/disk/by-id and /dev/disk/by-path - can easily switch a disk between emulated and passthrough modes; Disadvantages: - does not extend to scsi-generic and to host passthrough; 3) something between (1) and (2). If I understand correctly http://www.redhat.com/archives/libvir-list/2008-July/msg00429.html this would use <hostdev mode='capability'>. More on this below. SCSI target/host passthrough: rethinking <hostdev mode='capability'> ==================================================================== SCSI target/host passthrough passes the entire set of LUNs attached to a SCSI target or host. On the QEMU side, this is done manually by adding a scsi_block or scsi_generic device for each LUN. This can be realized using something like: <hostdev mode='subsystem' type='scsi_host'> <source> <address type='scsi' host='...'/> </source> <address type='scsi' host='...'/> </hostdev> <hostdev mode='subsystem' type='scsi_target'> <source> <address type='scsi' host='...' bus='...' target='...'/> </source> <address type='scsi' host='...' bus='...' target='...'/> </hostdev> However, as for LUN passthrough, the main problem is that Linux host indices are not stable. Thus, in this case using <hostdev mode='capability'> seems like the only reasonable possibility. That said, <hostdev mode='capability'> has never been documented and never even implemented. For this reason, I'm proposing to redo its functionality in a different way. The two examples given in http://www.redhat.com/archives/libvir-list/2008-July/msg00429.html were the following: > A network card by name (ie for OpenVZ) > > <hostdev mode='capability'> > <source name='eth0'/> > </hostdev> > > A SCSI device by name (eg, SCSI PV passthrough), also specifying > the target adress > > <hostdev mode='capability' type='scsi'> > <source name='sg3'/> > <target address='0:0:0:0'/> > </hostdev> In my proposal: 1) the "mode" attribute is dropped (more precisely, only "subsystem" is allowed and never printed; everything else is rejected); 2) the "type" attribute can in principle get any value that is valid for a nodedev capability---more or less: for example the usb type maps to the usb_device capability; :( 3) the "source" element can get a name "attribute" pointing to a nodedev name, and a "rel" attribute that is "child" or "parent". "child" instructs libvirt to search for a device possessing the given capability, and that is a child of the named device; "parent" instructs libvirt to pick the parent of the indicated device. When the "name" attribute is included, the element must be empty. Given this, here is how the two examples above would look like: A network card for OpenVZ: - by name (has adding aliases for nodedevs ever been considered, such as simply "eth0" in this case?): <hostdev type='net'> <source name='net_eth0_00_22_68_0b_dc_ac'/> </hostdev> - by position: <hostdev type='net'> <source rel='child' name='pci_0000_00_19_0'/> </hostdev> A SCSI device: - by name: <hostdev type='scsi'> <source name='scsi_0_0_0_0'/> <address type='scsi' host='...' bus='...' target='...' lun='...'/> </hostdev> - by position (aliases also would allow to specify /dev/sda easily): <hostdev type='scsi'> <source rel='parent' name='block_sda_ST9160411AS_5TG11QWL'/> <address type='scsi' host='...' bus='...' target='...' lun='...'/> </hostdev> A SCSI host: - by name: <hostdev type='scsi_host'> <source name='scsi_host0'/> <address type='scsi' host='...'/> </hostdev> - by position: <hostdev type='scsi_host'> <source rel='child' name='pci_0000_00_1f_2'/> <address type='scsi' host='...'/> </hostdev> NPIV support: generalizing hostdev source addresses =================================================== In NPIV, a virtual HBA is created using "virsh nodedev-create" and passed to the guest. Such virtual adapter does have a stable address, namely its WWN. As such, it can be addressed simply by generalizing the kind of source address that can be passed to <hostdev type='scsi_host'/>: <hostdev type='scsi_host'> <source> <address type='wwn' wwpn='...' wwnn='...'/> </source> </hostdev> (Note that this doesn't use <source name='...'/> and, as such, it does not rely on the ideas above). Ideas and opinions are welcome! Paolo

4 5

[libvirt] [PATCH] lxc: remove dummy function
by ajia＠redhat.com 27 Oct '11

27 Oct '11

From: Alex Jia <ajia(a)redhat.com> Cppcheck detected a syntaxError on lxcDomainInterfaceStats, my initial patch added a '{' to reserve 'else' branch to avoid a syntax error, in fact, don't need the dummy function in 'else' branch. * src/lxc/lxc_driver.c: remove dummy function entirely. Signed-off-by: Alex Jia <ajia(a)redhat.com> --- src/lxc/lxc_driver.c | 9 --------- 1 files changed, 0 insertions(+), 9 deletions(-) diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index 06bfa85..251fa92 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -2666,15 +2666,6 @@ cleanup: virDomainObjUnlock(vm); return ret; } -#else -static int -lxcDomainInterfaceStats(virDomainPtr dom, - const char *path ATTRIBUTE_UNUSED, - struct _virDomainInterfaceStats *stats ATTRIBUTE_UNUSED) -{ - lxcError(VIR_ERR_NO_SUPPORT, "%s", __FUNCTION__); - return -1; -} #endif static int lxcDomainGetAutostart(virDomainPtr dom, -- 1.7.1

2 1