[one-users] How to change a bridge in a already created vnet

[Carlos Martín Sánchez]

Hi,

On Fri, Oct 19, 2012 at 10:35 AM, Valentin Bud <valentin at hackaserver.com>
 wrote:

>
> `onevnet` can also update the NETWORK_MASK. Can someone from OpenNebula
> dev answer with a small explanation why can't other attributes be change
> using `onevnet update`?


The update command will only change the attributes of the VNet template,
not the "internal" attributes . If you take a look at the xml output of
'onevnet show id -x', the bridge is VNET/BRIDGE, whereas the network mask
is VNET/TEMPLATE/NETWORK_MASK


If it is really useful, we can add the option to update specific internal
attributes. For example, the 'onedatastore update' command will let you
update the internal DS_MAD and TM_MAD attributes.

Regards

--
Carlos Martín, MSc
Project Engineer
OpenNebula - The Open-source Solution for Data Center Virtualization
www.OpenNebula.org | cmartin at opennebula.org |
@OpenNebula<http://twitter.com/opennebula><cmartin at opennebula.org>



On Fri, Oct 19, 2012 at 10:35 AM, Valentin Bud <valentin at hackaserver.com>wrote:

> Hello Alvaro,
>
> On Fri, Oct 19, 2012 at 10:02:16AM +0200, Alvaro Simon wrote:
> > Hi Valentin:
> >
> > Thanks a lot for your quick answer
> > > On Thu, Oct 18, 2012 at 06:16:22PM +0200, Alvaro Simon wrote:
> > >> Dear OpenNebula developers
> > >>
> > >> We have crated a fixed virtual network some time ago with a specific
> > >> bridge (virbrA).
> > >>
> > >> Now we did some changes in our network, we are using a new IP rank but
> > >> for practical reasons we want to still use the same vnetid. We have
> > >> updated our vnet to change its bridge (by virbrB) but when we
> > >> instantiate new machines, the IP is assigned correctly but it still
> uses
> > >> the old bridge name (virbrA). How we can change the bridge name
> without
> > >> create a new vnet?
> > >
> > > I suppose you mean the name of the bridge from virtual network with ID,
> > > for example 7.
> > >
> >
> > Yes, exactly and executing
> > '#onevnet update 294' is not enough
>
> `onevnet` can also update the NETWORK_MASK. Can someone from OpenNebula
> dev answer with a small explanation why can't other attributes be change
> using `onevnet update`?
>
> >
> > > If you use MySQL as a database the following steps work.
> > >
> > > $ onevnet list | grep 7
> > >    7 wiz          oneadmin     test            -               R test 0
> > >
> > > $ mysql -u root -p
> > > use opennebula;
> > > update network_pool set
> body='<VNET><ID>7</ID><UID>2</UID><GID>0</GID><UNAME>wiz</UNAME><GNAME>oneadmin</GNAME><NAME>test</NAME><PERMISSIONS><OWNER_U>1</OWNER_U><OWNER_M>1</OWNER_M><OWNER_A>0</OWNER_A><GROUP_U>0</GROUP_U><GROUP_M>0</GROUP_M><GROUP_A>0</GROUP_A><OTHER_U>0</OTHER_U><OTHER_M>0</OTHER_M><OTHER_A>0</OTHER_A></PERMISSIONS><CLUSTER_ID>-1</CLUSTER_ID><CLUSTER></CLUSTER><TYPE>0</TYPE><BRIDGE>*virbrB*</BRIDGE><VLAN>1</VLAN><PHYDEV/><VLAN_ID>3</VLAN_ID><RANGE><IP_START>192.168.18.50</IP_START><IP_END>192.168.18.254</IP_END></RANGE><TOTAL_LEASES>0</TOTAL_LEASES><TEMPLATE><NETWORK_MASK><![CDATA[255.255.255.0]]></NETWORK_MASK></TEMPLATE></VNET>'
> where oid=7;
> > > quit
> > >
> > > And the next step would be to check if that really changed things:
> > > $ onevnet list | grep 7
> > >    7 wiz          oneadmin     test            -               R
> virbrB 0
> > >
> > > I didn't come up with the `body` data. I just copied it using the
> > > following MySQL query:
> > >
> > > use opennebula;
> > > select body from network_pool where oid=7 \G
> >
> >
> > We have checked as you have suggested ON database, and yes the xml field
> > was not updated... (maybe is this an ON issue?)
> >
> >
>  <VNET><ID>294</ID><UID>19</UID><GID>128</GID><UNAME>egitest</UNAME><GNAME>egi</GNAME><NAME>EGI
> fedcloud</NAME><PERMISSIONS><OWNER_U>1</OWNER_U><OWNER_M>1</OWNER_M><OWNER_A>0</OWNER_A><GROUP_U>1</GROUP_U><GROUP_M>0</GROUP_M><GROUP_A>0</GROUP_A><OTHER_U>0</OTHER_U><OTHER_M>0</OTHER_M><OTHER_A>0</OTHER_A></PERMISSIONS><TYPE>1</TYPE><BRIDGE>virbrA</BRIDGE><VLAN>0</VLAN><PHYDEV/><VLAN_ID/><TOTAL_LEASES>2</TOTAL_LEASES><TEMPLATE><BRIDGE><![CDATA[virbrB]]></BRIDGE><DNS><![CDATA[xxx.xxx.xxx.xxx
> xxx.xxx.xxx.xxx]]></DNS><GATEWAY><![CDATA[xxx.xxx.xxx.xxx]]></GATEWAY><LEASES><IP><![CDATA[xxx.xxx.xxx.xxx]]></IP></LEASES><LEASES><IP><![CDATA[xxx.xxx.xxx.xxx]]></IP></LEASES><LEASES><IP><![CDATA[xxx.xxx.xxx.xxx]]></IP></LEASES><LEASES><IP><![CDATA[xxx.xxx.xxx.xxx]]></IP></LEASES><NAME><![CDATA[EGI
> fedcloud]]></NAME><TYPE><![CDATA[FIXED]]></TYPE></TEMPLATE></VNET>
> >
> >
> > It was changed <BRIDGE><![CDATA[virbrB]]></BRIDGE>, but
> > <BRIDGE>virbrA</BRIDGE> is still the same so the VMs are not
> > instantiated correctly.
> >
> > We have changed it (<BRIDGE>virbrB</BRIDGE>
> > ..<BRIDGE><![CDATA[virbrB]]></BRIDGE>...) and now its working fine.
>
> Thanks for pointing this out. I have never actually needed to do this
> but it was a nice OpenNebula exercise and now we know how we change
> stuff in the database if we need too :).
>
> >
> >
> > Cheers and thanks!
> > Alvaro
> >
>
> Cheers & Goodwill,
> v
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20121030/111d8fbc/attachment-0002.htm>