You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Edison Su <Ed...@citrix.com> on 2013/08/30 02:04:51 UTC

[ACS42] KVM upgrade path to 4.2

There is a bug related to KVM upgrade: CLOUDSTACK-4405. The main issue is related to guest network bridge name schema is changed, thus migrate vm, create new vm will have problem after upgraded to 4.2.
If you are using basic network, then don't need to do the following steps.
The proposed upgrade paths are:
1. Stick to old network name in 4.2. You can set "network.bridge.name.schema=3.0" in /etc/cloudstack/agent/agent.properties
2. Upgrade to new network name schema, need to do the following steps:
      a. Install 4.2 cloudstack agent on each kvm host
      b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing bridge name to new bridge name.
      c. install a libvirt hook: 
           c1. mkdir /etc/libvirt/hooks
           c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook /etc/libvirt/hooks/qemu
           c3. chmod +x /etc/libvirt/hooks/qemu
           c4. service libvirtd restart
           c5. service cloudstack-agent restart
The potential issues if you are using above upgrade path 2:
1. If you are using multiple physical bridges, other than the one specified in "guest.network.device" in /etc/cloudstack/agent/agent.properties, then the vm live migration may have problem.
2. Advanced zone with security group, wont' work.
3. may have old iptables rules left on kvm host, it shouldn't impact guest connectivity though.

Re: [ACS42] KVM upgrade path to 4.2

Posted by Marcus Sorensen <sh...@gmail.com>.
You might look in /sys/devices/virtual/net, the code traverses each
device listed here (each directory), looks for a file called 'bridge',
and adds it to a list of bridges. Then it iterates through that list
and sees if the name of the bridge matches the KVM traffic label for
public, guest traffic. If it does, it looks up the physical device
enslaved to that bridge and keeps track of it in the _pifs variable.
So first look at the info there and make sure it's populated correctly
on your system (both the KVM traffic label and the bridge files/names
exist in that location).

Now, how it translates a bridge to a physical device also needs to be
looked at. It opens /sys/devices/virtual/net/$bridgename/brif
directory, iterates through the files, and looks for one starting with
eth, bond, vlan, em, or p*p*. The brif directory generally only has
the uplink device and vnet devices (the vm interfaces).

So look around your system and see if anything doesn't look right
according to that. If the brif directory looks good, then I wonder if
you have no traffic labels set and the default detection isn't
working.

On Fri, Sep 6, 2013 at 3:36 PM, Edison Su <Ed...@citrix.com> wrote:
> Is there a bridge created on brondg on your kvm host?
> The current kvm code will look for all the bridge devices on your kvm host first, then find out its corresponding physical nic device.
>
>> -----Original Message-----
>> From: Kelcey Jamison Damage [mailto:kelcey@backbonetechnology.com]
>> Sent: Friday, September 06, 2013 2:19 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [ACS42] KVM upgrade path to 4.2
>>
>> Question for you guys,
>>
>> I updated the schema on my 4.1.1 cloud. For the most part it works, but
>> some hosts that I've updated now fail to deploy VMs do to the following
>> error:
>>
>> -- Instead of creating a guest bridge called 'brbondg-1200' it tries to create
>> 'br-1200' as if it can not detect my interface names.
>>
>> Any thoughts?
>>
>> ----- Original Message -----
>> From: "Prasanna Santhanam" <ts...@apache.org>
>> To: dev@cloudstack.apache.org
>> Sent: Friday, August 30, 2013 9:51:53 AM
>> Subject: Re: [ACS42] KVM upgrade path to 4.2
>>
>> Hi Edison,
>>
>> I've just added these steps to the doc bug that was linked to the it at
>> CLOUDSTACK-4550
>>
>>
>> On Fri, Aug 30, 2013 at 12:04:51AM +0000, Edison Su wrote:
>> > There is a bug related to KVM upgrade: CLOUDSTACK-4405. The main issue
>> is related to guest network bridge name schema is changed, thus migrate vm,
>> create new vm will have problem after upgraded to 4.2.
>> > If you are using basic network, then don't need to do the following steps.
>> > The proposed upgrade paths are:
>> > 1. Stick to old network name in 4.2. You can set
>> > "network.bridge.name.schema=3.0" in
>> > /etc/cloudstack/agent/agent.properties
>> > 2. Upgrade to new network name schema, need to do the following steps:
>> >       a. Install 4.2 cloudstack agent on each kvm host
>> >       b. Run "cloudstack-agent-upgrade". This script will upgrade all the
>> existing bridge name to new bridge name.
>> >       c. install a libvirt hook:
>> >            c1. mkdir /etc/libvirt/hooks
>> >            c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook
>> /etc/libvirt/hooks/qemu
>> >            c3. chmod +x /etc/libvirt/hooks/qemu
>> >            c4. service libvirtd restart
>> >            c5. service cloudstack-agent restart The potential issues
>> > if you are using above upgrade path 2:
>> > 1. If you are using multiple physical bridges, other than the one specified in
>> "guest.network.device" in /etc/cloudstack/agent/agent.properties, then the
>> vm live migration may have problem.
>> > 2. Advanced zone with security group, wont' work.
>> > 3. may have old iptables rules left on kvm host, it shouldn't impact guest
>> connectivity though.
>>
>> --
>> Prasanna.,
>>
>> ------------------------
>> Powered by BigRock.com
>

RE: [ACS42] KVM upgrade path to 4.2

Posted by Edison Su <Ed...@citrix.com>.
Is there a bridge created on brondg on your kvm host?
The current kvm code will look for all the bridge devices on your kvm host first, then find out its corresponding physical nic device.

> -----Original Message-----
> From: Kelcey Jamison Damage [mailto:kelcey@backbonetechnology.com]
> Sent: Friday, September 06, 2013 2:19 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [ACS42] KVM upgrade path to 4.2
> 
> Question for you guys,
> 
> I updated the schema on my 4.1.1 cloud. For the most part it works, but
> some hosts that I've updated now fail to deploy VMs do to the following
> error:
> 
> -- Instead of creating a guest bridge called 'brbondg-1200' it tries to create
> 'br-1200' as if it can not detect my interface names.
> 
> Any thoughts?
> 
> ----- Original Message -----
> From: "Prasanna Santhanam" <ts...@apache.org>
> To: dev@cloudstack.apache.org
> Sent: Friday, August 30, 2013 9:51:53 AM
> Subject: Re: [ACS42] KVM upgrade path to 4.2
> 
> Hi Edison,
> 
> I've just added these steps to the doc bug that was linked to the it at
> CLOUDSTACK-4550
> 
> 
> On Fri, Aug 30, 2013 at 12:04:51AM +0000, Edison Su wrote:
> > There is a bug related to KVM upgrade: CLOUDSTACK-4405. The main issue
> is related to guest network bridge name schema is changed, thus migrate vm,
> create new vm will have problem after upgraded to 4.2.
> > If you are using basic network, then don't need to do the following steps.
> > The proposed upgrade paths are:
> > 1. Stick to old network name in 4.2. You can set
> > "network.bridge.name.schema=3.0" in
> > /etc/cloudstack/agent/agent.properties
> > 2. Upgrade to new network name schema, need to do the following steps:
> >       a. Install 4.2 cloudstack agent on each kvm host
> >       b. Run "cloudstack-agent-upgrade". This script will upgrade all the
> existing bridge name to new bridge name.
> >       c. install a libvirt hook:
> >            c1. mkdir /etc/libvirt/hooks
> >            c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook
> /etc/libvirt/hooks/qemu
> >            c3. chmod +x /etc/libvirt/hooks/qemu
> >            c4. service libvirtd restart
> >            c5. service cloudstack-agent restart The potential issues
> > if you are using above upgrade path 2:
> > 1. If you are using multiple physical bridges, other than the one specified in
> "guest.network.device" in /etc/cloudstack/agent/agent.properties, then the
> vm live migration may have problem.
> > 2. Advanced zone with security group, wont' work.
> > 3. may have old iptables rules left on kvm host, it shouldn't impact guest
> connectivity though.
> 
> --
> Prasanna.,
> 
> ------------------------
> Powered by BigRock.com


Re: [ACS42] KVM upgrade path to 4.2

Posted by Kelcey Jamison Damage <ke...@backbonetechnology.com>.
Question for you guys,

I updated the schema on my 4.1.1 cloud. For the most part it works, but some hosts that I've updated now fail to deploy VMs do to the following error:

-- Instead of creating a guest bridge called 'brbondg-1200' it tries to create 'br-1200' as if it can not detect my interface names.

Any thoughts?

----- Original Message -----
From: "Prasanna Santhanam" <ts...@apache.org>
To: dev@cloudstack.apache.org
Sent: Friday, August 30, 2013 9:51:53 AM
Subject: Re: [ACS42] KVM upgrade path to 4.2

Hi Edison,

I've just added these steps to the doc bug that was linked to the
it at CLOUDSTACK-4550


On Fri, Aug 30, 2013 at 12:04:51AM +0000, Edison Su wrote:
> There is a bug related to KVM upgrade: CLOUDSTACK-4405. The main issue is related to guest network bridge name schema is changed, thus migrate vm, create new vm will have problem after upgraded to 4.2.
> If you are using basic network, then don't need to do the following steps.
> The proposed upgrade paths are:
> 1. Stick to old network name in 4.2. You can set "network.bridge.name.schema=3.0" in /etc/cloudstack/agent/agent.properties
> 2. Upgrade to new network name schema, need to do the following steps:
>       a. Install 4.2 cloudstack agent on each kvm host
>       b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing bridge name to new bridge name.
>       c. install a libvirt hook: 
>            c1. mkdir /etc/libvirt/hooks
>            c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook /etc/libvirt/hooks/qemu
>            c3. chmod +x /etc/libvirt/hooks/qemu
>            c4. service libvirtd restart
>            c5. service cloudstack-agent restart
> The potential issues if you are using above upgrade path 2:
> 1. If you are using multiple physical bridges, other than the one specified in "guest.network.device" in /etc/cloudstack/agent/agent.properties, then the vm live migration may have problem.
> 2. Advanced zone with security group, wont' work.
> 3. may have old iptables rules left on kvm host, it shouldn't impact guest connectivity though.

-- 
Prasanna.,

------------------------
Powered by BigRock.com


Re: [ACS42] KVM upgrade path to 4.2

Posted by Prasanna Santhanam <ts...@apache.org>.
Hi Edison,

I've just added these steps to the doc bug that was linked to the
it at CLOUDSTACK-4550


On Fri, Aug 30, 2013 at 12:04:51AM +0000, Edison Su wrote:
> There is a bug related to KVM upgrade: CLOUDSTACK-4405. The main issue is related to guest network bridge name schema is changed, thus migrate vm, create new vm will have problem after upgraded to 4.2.
> If you are using basic network, then don't need to do the following steps.
> The proposed upgrade paths are:
> 1. Stick to old network name in 4.2. You can set "network.bridge.name.schema=3.0" in /etc/cloudstack/agent/agent.properties
> 2. Upgrade to new network name schema, need to do the following steps:
>       a. Install 4.2 cloudstack agent on each kvm host
>       b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing bridge name to new bridge name.
>       c. install a libvirt hook: 
>            c1. mkdir /etc/libvirt/hooks
>            c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook /etc/libvirt/hooks/qemu
>            c3. chmod +x /etc/libvirt/hooks/qemu
>            c4. service libvirtd restart
>            c5. service cloudstack-agent restart
> The potential issues if you are using above upgrade path 2:
> 1. If you are using multiple physical bridges, other than the one specified in "guest.network.device" in /etc/cloudstack/agent/agent.properties, then the vm live migration may have problem.
> 2. Advanced zone with security group, wont' work.
> 3. may have old iptables rules left on kvm host, it shouldn't impact guest connectivity though.

-- 
Prasanna.,

------------------------
Powered by BigRock.com