cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Vanderford (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used
Date Tue, 27 May 2014 20:05:02 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010199#comment-14010199
] 

Bob Vanderford commented on CLOUDSTACK-6464:
--------------------------------------------

We also have had trouble similar to this issue.  We did not upgrade, just started with version
4.3 in a prototype environment using advanced networking.  Here is were we got in troubleshooting
this.

We found what seems to be a redundant interface on the virtual router for the network (isolated),
eth3.  Eth2 is the public interface but eth3 has the same public ip address assigned as eth2.
 Now we see the following iptables rule on the virtual router:

iptables -t nat -A POSTROUTING -j SNAT -o eth3 --to-source=<ip address>

We delete this rule using the -D form of the iptables command and then added the rule back
but using eth2 instead of eth3, like this:

iptables -t nat -A POSTROUTING -j SNAT -o eth2 --to-source=<ip address>

After that the instance(s) on that network have egress and can access the public internet.
 This is not an acceptable workaround, however, since users won't have access to the virtual
router.  But, it does demonstrate the nature of the issue.

So, either the eth3 interface shouldn't be there at all or the iptables rule needs to apply
its rule to eth2 rather than eth3.

This issue essentially makes version 4.3 unusable for us.  To have an effect instance it must
be able to access the Internet for patch updates, downloading files, etc.  We would consider
this a blocking issue and deserving of a patch or a quick release for 4.3.1 if such a thing
is possible.

If there is another workaround in meantime, we would be happy to use it.  

Also, note, this is a prototype environment and we can provide access to the management portal
to anyone that would be interested in debugging or trying a patch.

> [KVM:basic zone- upgrade to  4.3],after   any vm restart,all the nics  are plugged to
default bridge even though trafiic labels are being used
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-6464
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.3.0
>            Reporter: sadhu suresh
>            Priority: Critical
>             Fix For: 4.4.0
>
>
>  Steps:
> 1. create a KVM basic zone with 2 nics on host (pre 4.3 build)
> 2.use cloudbr0 for management and cloudbr1 for guest by specifying the traffic labels
in the physical networks.
> 3.deploy few vms
> 4.upgrade to felton GA build as per the Upgrade instructions.
> actual result:
> Upgrade successful but all the vnets that were attached to cloudbr1 before upgrade are
attached to cloudbr0.
> Due to this network connectivity is lost.
> Expected result:
> Even after upgrade ,all the vnets should be attached to the same bridge as before upgrade.
> ex:
> before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after upgrade
and VM stop/start.
> the network rules are getting programmed in cloudbr0 .check below output
> ,984 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Executing:
/usr/share/cloudstack-common/scripts/vm/network/security_group.py default_network_rules --vmname
i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0
--nicsecips 0:
> dumpxml output for i-5-616-VM after upgrade(& after VM restart)
> *****************************************************
> virsh # dumpxml 38
> <domain type='kvm' id='38'>
> <name>i-5-616-VM</name>
> <uuid>87557942-1393-49b3-a73e-ae24c40541d1</uuid>
> <description>Other CentOS (64-bit)</description>
> <memory unit='KiB'>2097152</memory>
> <currentMemory unit='KiB'>2097152</currentMemory>
> <vcpu placement='static'>1</vcpu>
> <cputune>
> <shares>1000</shares>
> </cputune>
> <os>
> <type arch='x86_64' machine='rhel6.2.0'>hvm</type>
> <boot dev='cdrom'/>
> <boot dev='hd'/>
> </os>
> <features>
> <acpi/>
> <apic/>
> <pae/>
> </features>
> <cpu>
> </cpu>
> <clock offset='utc'/>
> <on_poweroff>destroy</on_poweroff>
> <on_reboot>restart</on_reboot>
> <on_crash>destroy</on_crash>
> <devices>
> <emulator>/usr/libexec/qemu-kvm</emulator>
> <disk type='file' device='disk'>
> <driver name='qemu' type='qcow2' cache='none'/>
> <source file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/>
> <target dev='hda' bus='ide'/>
> <alias name='ide0-0-0'/>
> <address type='drive' controller='0' bus='0' target='0' unit='0'/>
> </disk>
> <disk type='file' device='cdrom'>
> <driver name='qemu' type='raw' cache='none'/>
> <target dev='hdc' bus='ide'/>
> <readonly/>
> <alias name='ide0-1-0'/>
> <address type='drive' controller='0' bus='1' target='0' unit='0'/>
> </disk>
> <controller type='usb' index='0'>
> <alias name='usb0'/>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
> </controller>
> <controller type='ide' index='0'>
> <alias name='ide0'/>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
> </controller>
> <interface type='bridge'>
> <mac address='06:14:48:00:00:7f'/>
> <source bridge='cloudbr0'/>
> <target dev='vnet15'/>
> <model type='e1000'/>
> <bandwidth>
> <inbound average='25600' peak='25600'/>
> <outbound average='25600' peak='25600'/>
> </bandwidth>
> <alias name='net0'/>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
> </interface>
> <serial type='pty'>
> <source path='/dev/pts/12'/>
> <target port='0'/>
> <alias name='serial0'/>
> </serial>
> <console type='pty' tty='/dev/pts/12'>
> <source path='/dev/pts/12'/>
> <target type='serial' port='0'/>
> <alias name='serial0'/>
> </console>
> <input type='tablet' bus='usb'>
> <alias name='input0'/>
> </input>
> <input type='mouse' bus='ps2'/>
> <graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3'>
> <listen type='address' address='10.147.37.3'/>
> </graphics>
> <video>
> <model type='cirrus' vram='9216' heads='1'/>
> <alias name='video0'/>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
> </video>
> <memballoon model='virtio'>
> <alias name='balloon0'/>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
> </memballoon>
> </devices>
> <seclabel type='none'/>
> </domain>
> its also applicable to new vm deployments.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message