Bug 1126487
Summary: | virsh and perl-Sys-Virt unable to update active running device interface | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Jarrod Makin <jarrod.makin> |
Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.6 | CC: | berrange, dyuan, honzhang, jarrod.makin, mzhan, rbalakri |
Target Milestone: | rc | Keywords: | MoveUpstream |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-0.10.2-49.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-07-22 05:46:25 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jarrod Makin
2014-08-04 14:27:55 UTC
I argue this is a bug rather than an enhancement request and confirm its presence in libvirt-0.10.2-46.el6_6.1.x86_64 and libvirt-client-0.10.2-46.el6_6.1.x86_64 Documentation for perl-Sys-Virt at http://search.cpan.org/~danberr/Sys-Virt-0.10.2/lib/Sys/Virt/Domain.pm#DEVICE_HOTPLUG_OPTIONS suggests it should be possible to update a running domain's devices not just the persistent configuration. Re-assigning to libvirt, since the perl API binding doesn't influence functional results of the API calls. (In reply to Jarrod Makin from comment #3) > I argue this is a bug rather than an enhancement request and confirm its > presence in libvirt-0.10.2-46.el6_6.1.x86_64 and > libvirt-client-0.10.2-46.el6_6.1.x86_64 > > Documentation for perl-Sys-Virt at > http://search.cpan.org/~danberr/Sys-Virt-0.10.2/lib/Sys/Virt/Domain. > pm#DEVICE_HOTPLUG_OPTIONS suggests it should be possible to update a running > domain's devices not just the persistent configuration. Well, if I try to update the device I get 'not supported' error message. Why it should be a bug fix rather than an enhancement then? virsh # update-device test interface-definition.xml error: Failed to update device from interface-definition.xml error: this function is not supported by the connection driver: unable to change config on 'bridge' network type BTW: what's the domain XML? The interface must be already present there. BTW2: There's a workaround: detach and attach the interface again. Hi Michal, I hope I am able to answer some of your questions. I have never received the 'not supported' error message. Additionally, I am unable to follow the link in your second post as I cannot resolve post-office.corp.redhat.com. By domain XML, I refer to either the persistent definition in /etc/libvirt/qemu or the currently active definition in /var/run/libvirt/qemu I have tried the workaround and find it sometimes doesn't work on certain guest operating systems, particularly older Ubuntus and some Windows. Instead, the detach works but then the attach fails, leaving my guests without any network. My intention is to be able to restrict my users to only be able to raise a certain selection of ip address, and change that on the fly with these commands rather than manually invoke ebtables. The reason I think of it as a bug, is because sometimes attach-device fails and because update-device successfully updates the persistent definition, but makes no change to the currently active definition or change the ebtables rules. The reason I think an enhancement request might be more suitable is because there is currently no {attach/detach/update} interface, only {attach/detach/update} device. Verify it as follows. The result is expected. # rpm -q libvirt libvirt-0.10.2-49.el6.x86_64 # virsh start rhel6.5 Domain rhel6.5 started # virsh dumpxml rhel6.5|grep interface -A8 <interface type='network'> <mac address='52:54:00:f5:c6:22'/> <source network='default'/> <target dev='vnet0'/> <model type='virtio'/> <filterref filter='clean-traffic'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> # ebtables -t nat -L Bridge table: nat Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j libvirt-I-vnet0 Bridge chain: OUTPUT, entries: 0, policy: ACCEPT Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT -o vnet0 -j libvirt-O-vnet0 Bridge chain: libvirt-I-vnet0, entries: 9, policy: ACCEPT -j I-vnet0-mac -p IPv4 -j I-vnet0-ipv4-ip -p IPv4 -j ACCEPT -p ARP -j I-vnet0-arp-mac -p ARP -j I-vnet0-arp-ip -p ARP -j ACCEPT -p 0x8035 -j I-vnet0-rarp -p 0x835 -j ACCEPT -j DROP Bridge chain: libvirt-O-vnet0, entries: 4, policy: ACCEPT -p IPv4 -j O-vnet0-ipv4 -p ARP -j ACCEPT -p 0x8035 -j O-vnet0-rarp -j DROP Bridge chain: I-vnet0-mac, entries: 2, policy: ACCEPT -s 52:54:0:f5:c6:22 -j RETURN -j DROP Bridge chain: I-vnet0-ipv4-ip, entries: 3, policy: ACCEPT -p IPv4 --ip-src 0.0.0.0 --ip-proto udp -j RETURN -p IPv4 --ip-src 192.168.122.12 -j RETURN -j DROP Bridge chain: O-vnet0-ipv4, entries: 1, policy: ACCEPT -j ACCEPT Bridge chain: I-vnet0-arp-mac, entries: 2, policy: ACCEPT -p ARP --arp-mac-src 52:54:0:f5:c6:22 -j RETURN -j DROP Bridge chain: I-vnet0-arp-ip, entries: 2, policy: ACCEPT -p ARP --arp-ip-src 192.168.122.12 -j RETURN -j DROP Bridge chain: I-vnet0-rarp, entries: 2, policy: ACCEPT -p 0x8035 -s 52:54:0:f5:c6:22 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:f5:c6:22 --arp-mac-dst 52:54:0:f5:c6:22 -j ACCEPT -j DROP Bridge chain: O-vnet0-rarp, entries: 2, policy: ACCEPT -p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:f5:c6:22 --arp-mac-dst 52:54:0:f5:c6:22 -j ACCEPT -j DROP # cat interface.xml <interface type='network'> <mac address='52:54:00:f5:c6:22'/> <source network='default'/> <target dev='vnet0'/> <model type='virtio'/> <filterref filter="clean-traffic"> <parameter name="IP" value="1.2.3.4" /> <parameter name="IP" value="1.2.3.5" /> </filterref> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> # virsh update-device rhel6.5 interface.xml Device updated successfully # virsh dumpxml rhel6.5|grep interface -A10 <interface type='network'> <mac address='52:54:00:f5:c6:22'/> <source network='default'/> <target dev='vnet0'/> <model type='virtio'/> <filterref filter='clean-traffic'> <parameter name='IP' value='1.2.3.4'/> <parameter name='IP' value='1.2.3.5'/> </filterref> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> # ebtables -t nat -L Bridge table: nat Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j libvirt-I-vnet0 Bridge chain: OUTPUT, entries: 0, policy: ACCEPT Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT -o vnet0 -j libvirt-O-vnet0 Bridge chain: libvirt-I-vnet0, entries: 9, policy: ACCEPT -j I-vnet0-mac -p IPv4 -j I-vnet0-ipv4-ip -p IPv4 -j ACCEPT -p ARP -j I-vnet0-arp-mac -p ARP -j I-vnet0-arp-ip -p ARP -j ACCEPT -p 0x8035 -j I-vnet0-rarp -p 0x835 -j ACCEPT -j DROP Bridge chain: libvirt-O-vnet0, entries: 4, policy: ACCEPT -p IPv4 -j O-vnet0-ipv4 -p ARP -j ACCEPT -p 0x8035 -j O-vnet0-rarp -j DROP Bridge chain: I-vnet0-mac, entries: 2, policy: ACCEPT -s 52:54:0:f5:c6:22 -j RETURN -j DROP Bridge chain: I-vnet0-ipv4-ip, entries: 4, policy: ACCEPT -p IPv4 --ip-src 0.0.0.0 --ip-proto udp -j RETURN -p IPv4 --ip-src 1.2.3.4 -j RETURN -p IPv4 --ip-src 1.2.3.5 -j RETURN -j DROP Bridge chain: O-vnet0-ipv4, entries: 1, policy: ACCEPT -j ACCEPT Bridge chain: I-vnet0-arp-mac, entries: 2, policy: ACCEPT -p ARP --arp-mac-src 52:54:0:f5:c6:22 -j RETURN -j DROP Bridge chain: I-vnet0-arp-ip, entries: 3, policy: ACCEPT -p ARP --arp-ip-src 1.2.3.4 -j RETURN -p ARP --arp-ip-src 1.2.3.5 -j RETURN -j DROP Bridge chain: I-vnet0-rarp, entries: 2, policy: ACCEPT -p 0x8035 -s 52:54:0:f5:c6:22 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:f5:c6:22 --arp-mac-dst 52:54:0:f5:c6:22 -j ACCEPT -j DROP Bridge chain: O-vnet0-rarp, entries: 2, policy: ACCEPT -p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:f5:c6:22 --arp-mac-dst 52:54:0:f5:c6:22 -j ACCEPT -j DROP Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1252.html |