Hi, On Fri, Oct 19, 2012 at 10:35 AM, Valentin Bud <valen...@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 | cmar...@opennebula.org | @OpenNebula<http://twitter.com/opennebula><cmar...@opennebula.org> On Fri, Oct 19, 2012 at 10:35 AM, Valentin Bud <valen...@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@lists.opennebula.org > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >
_______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org