Re: [Users] Network reconfiguration in ovirt 3.1
On Sun, 23 Dec 2012 21:54:01 + Alex Leonhardt alex.t...@gmail.com wrote: I've had the same issue, turns out it resets itself everytime you configure the network interfaces *and* although you fix it it wont save the config until I saw the tick box (scroll down) to do so ;) ... Caught me up a couple times and was going to report it as a bug next week. The solution is not to reset the node, it's to manually reconfigure the NIC to have the same / old IP address, the node will come back to live which then enables you to re-save the network config by setting it to manual and ticking the box ;) My opinion is that ovirt engine should _NOT_ touch automatically OS networking at all without confirmation of the user! I haven't read the code but it seems it is using first available network interface. What about it my first network interfaces is dedicated for special purpose? I worked in a company where every server had 3 interfaces - 1st install/backup - 2nd service - 3rd admin. In this case ovirtmgmt should be on 3rd interface, not first one. I totally hate every autoreconfiguration without confirmation, this style pretends to be more clever that sysadmin and finally it sometimes break whole setup and needs manual reparation. jbelka ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Network reconfiguration in ovirt 3.1
On Thu, Dec 27, 2012 at 11:51:00AM +0100, Jiri Belka wrote: On Sun, 23 Dec 2012 21:54:01 + Alex Leonhardt alex.t...@gmail.com wrote: I've had the same issue, turns out it resets itself everytime you configure the network interfaces *and* although you fix it it wont save the config until I saw the tick box (scroll down) to do so ;) ... Caught me up a couple times and was going to report it as a bug next week. The solution is not to reset the node, it's to manually reconfigure the NIC to have the same / old IP address, the node will come back to live which then enables you to re-save the network config by setting it to manual and ticking the box ;) My opinion is that ovirt engine should _NOT_ touch automatically OS networking at all without confirmation of the user! I haven't read the code but it seems it is using first available network interface. What about it my first network interfaces is dedicated for special purpose? I worked in a company where every server had 3 interfaces - 1st install/backup - 2nd service - 3rd admin. In this case ovirtmgmt should be on 3rd interface, not first one. Actually ovirtmgmt is built on top the interface leading towards Engine. I totally hate every autoreconfiguration without confirmation, this style pretends to be more clever that sysadmin and finally it sometimes break whole setup and needs manual reparation. On the other hand, we need to define the management network when a host is added to the setup, and nagging for confirmation for each of them may lead us to the blind baboon acking syndrome. Since I'd like to normalize the way ovirtmgmt is created, and make it more like other networks, I've written up http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization If the Add Host dialog had a checkbox saying define ovirtmgmt network automatically, would it satisfy you? (any other comment to that feature page is welcome). regards, Dan. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] tagged vs untagged and sharing the interface
Hi You can have as many vlan as you want on the same interface. Just create a new interface on the cluster with the required vlan set, and associate it on each node on the cluster. Ovirtmgmt is attached by default to an untagged interface, and you can add vlan and configure your switch port in dual mode (native vlan on cisco ).So your physical interface will handle ovirtmgmt on native vlan and others vlan on vlan interface on node. Don't Forget to update ovirtmgmt interface when adding an interface to the node, or ovirtmgmt will be in DHCP. Kevin Le 27 déc. 2012 21:01, Jonathan Horne jho...@skopos.us a écrit : if someone could help me confirm, but it appear that i cannot co-populate tagged vlan on the same interface as ovirtmgmt? for me it would really be better if i can share these 2 on same interface, but if i can't ill just have to live with it. can any one confirm this? thanks, jonathan -- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Continuing my ovirt-3.2 nightlies queste
Hi All,
Thanks to the list help I'm now able to add hosts to my setup of
ovirt-3.2-nightlies on Fed17. Procedure in short:
install Fed17 from bfo.iso, so that I have minimal install, fix
networking-scripts, add danken virt repo en ovirt repo, yum update and
to minimize host add time yum install vdsm.
Sofar this has worked very well for 3 hosts. Now I would like to move 2
of those hosts to a Gluster enabled cluster. Putting them in maintanance
and then move them to the gluster cluster works for 1 of them and the
next gives an error. So remove the host and re-add it to the Gluster
cluster. Works OK, installs glusterfs and vdsm-gluster packages. Reboot
and detecting by mgmt works OK too.
Next step is on both hosts:
mkdir /gluster-data
chown -R 36:36 /gluster-data
gluster peer status -- no peers.
And then through the webadmin add a volume named gluster-data with paths
to st01:/gluster-data and st02:/gluster-data in replication mode, click
add -- Error
gluster peer status on both st01/2 shows the other server as connected,
gluster volume list -- gluster-data and gluster volume info gives more
info about the just entered info in the webadmin but I can't get an OK
there, cancelling the volume add gives me no volume in the webinterface.
Error in the vdsm.log on the storage hosts is:
MainProcess|Thread-153::DEBUG::2012-12-27
22:30:51,882::misc::84::Storage.Misc.excCmd::(lambda)
'/usr/sbin/gluster --mode=script volume info --xml' (cwd None)
MainProcess|Thread-153::DEBUG::2012-12-27
22:30:51,955::misc::84::Storage.Misc.excCmd::(lambda) SUCCESS: err =
''; rc = 0
MainProcess|Thread-153::ERROR::2012-12-27
22:30:51,956::supervdsmServer::80::SuperVdsm.ServerCallback::(wrapper)
Error in wrapper
Traceback (most recent call last):
File /usr/share/vdsm/supervdsmServer.py, line 78, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/supervdsmServer.py, line 313, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 45, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 431, in volumeInfo
raise ge.GlusterXmlErrorException(err=[etree.tostring(xmltree)])
GlusterXmlErrorException: XML error
error: cliOutputopRet0/opRetopErrno0/opErrnoopErrstr
/volInfovolumesvolumenamegluster-data/nameidaafc9a0b-1b17-4e1f-b441-7f9dfdb874db/idtype2/typestatus0/statusbrickCount2/brickCountdistCount2/distCountstripeCount1/stripeCountreplicaCount2/replicaCounttransport0/transportbricksbrickst01.nieuwland.nl:/gluster-data/brickbrickst02.nieuwland.nl:/gluster-data/brick/bricksoptCount0/optCountoptions
//volumecount1/count/volumes/volInfo/cliOutput
Thread-153::ERROR::2012-12-27
22:30:51,969::BindingXMLRPC::925::vds::(wrapper) vdsm exception occured
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 914, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 32, in wrapper
rv = func(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 56, in volumesList
return {'volumes': self.svdsmProxy.glusterVolumeInfo(volumeName)}
File /usr/share/vdsm/supervdsm.py, line 77, in __call__
return callMethod()
File /usr/share/vdsm/supervdsm.py, line 68, in lambda
**kwargs)
File string, line 2, in glusterVolumeInfo
File /usr/lib64/python2.7/multiprocessing/managers.py, line 773, in
_callmethod
raise convert_to_error(kind, result)
GlusterXmlErrorException: XML error
error: cliOutputopRet0/opRetopErrno0/opErrnoopErrstr
/volInfovolumesvolumenamegluster-data/nameidaafc9a0b-1b17-4e1f-b441-7f9dfdb874db/idtype2/typestatus0/statusbrickCount2/brickCountdistCount2/distCountstripeCount1/stripeCountreplicaCount2/replicaCounttransport0/transportbricksbrickst01.nieuwland.nl:/gluster-data/brickbrickst02.nieuwland.nl:/gluster-data/brick/bricksoptCount0/optCountoptions
//volumecount1/count/volumes/volInfo/cliOutput
versions:
rpm -aq | grep vdsm
vdsm-4.10.3-0.50.gitc6625ce.fc17.x86_64
vdsm-gluster-4.10.3-0.50.gitc6625ce.fc17.noarch
vdsm-xmlrpc-4.10.3-0.50.gitc6625ce.fc17.noarch
vdsm-cli-4.10.3-0.50.gitc6625ce.fc17.noarch
vdsm-python-4.10.3-0.50.gitc6625ce.fc17.x86_64
# rpm -aq | grep libvirt
libvirt-daemon-driver-qemu-0.10.1-2.fc17.x86_64
libvirt-daemon-driver-interface-0.10.1-2.fc17.x86_64
libvirt-daemon-driver-nwfilter-0.10.1-2.fc17.x86_64
libvirt-daemon-driver-libxl-0.10.1-2.fc17.x86_64
libvirt-client-0.10.1-2.fc17.x86_64
libvirt-daemon-driver-network-0.10.1-2.fc17.x86_64
libvirt-daemon-driver-lxc-0.10.1-2.fc17.x86_64
libvirt-lock-sanlock-0.10.1-2.fc17.x86_64
libvirt-daemon-driver-secret-0.10.1-2.fc17.x86_64
libvirt-daemon-driver-nodedev-0.10.1-2.fc17.x86_64
libvirt-daemon-config-network-0.10.1-2.fc17.x86_64
libvirt-daemon-driver-storage-0.10.1-2.fc17.x86_64
libvirt-0.10.1-2.fc17.x86_64
libvirt-python-0.10.1-2.fc17.x86_64
libvirt-daemon-0.10.1-2.fc17.x86_64
libvirt-daemon-driver-xen-0.10.1-2.fc17.x86_64
libvirt-daemon-config-nwfilter-0.10.1-2.fc17.x86_64
Re: [Users] [libvirt] Vdsm/libvir error during deploy
Osier Yang wrote:
On 2012年12月25日 00:15, Joop wrote:
Dan Kenigsberg wrote:
On Mon, Dec 24, 2012 at 02:18:48PM +0100, Joop wrote:
Dan Kenigsberg wrote:
Which version of libvirt is installed on your host?
libvirt-1.0.1-2.fc17.x86_64
libvirt-client-1.0.1-2.fc17.x86_64
libvirt-daemon-1.0.1-2.fc17.x86_64
libvirt-daemon-config-network-1.0.1-2.fc17.x86_64
libvirt-daemon-config-nwfilter-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-interface-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-lxc-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-network-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-nodedev-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-nwfilter-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-qemu-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-secret-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-storage-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-uml-1.0.1-2.fc17.x86_64
libvirt-daemon-driver-xen-1.0.1-2.fc17.x86_64
libvirt-lock-sanlock-1.0.1-2.fc17.x86_64
libvirt-python-1.0.1-2.fc17.x86_64
From virt-preview repo
[fedora-virt-preview]
name=Virtualization packages from Rawhide built for latest Fedora
baseurl=http://fedorapeople.org/groups/virt/virt-preview/fedora-$releasever/$basearch
enabled=1
skip_if_unavailable=1
gpgcheck=0
What is the output of the following python script on your machine?
Mine
says 1. Could it be that your libvirt says 0?
=
from vdsm import libvirtconnection
conn = libvirtconnection.get()
netXml = network
nametest/name
forward mode='passthrough'
interface dev='em1'/
/forward
/network
net = conn.networkDefineXML(netXml)
net.create()
print net.isPersistent()
net.destroy()
net.undefine()
0
libvir: Network Driver error : Network not found: no network with
matching uuid
Traceback (most recent call last):
File test.py, line 16, inmodule
net.undefine()
File /usr/lib64/python2.7/site-packages/libvirt.py, line 2154, in
undefine
if ret == -1: raise libvirtError ('virNetworkUndefine() failed',
net=self)
libvirt.libvirtError: Network not found: no network with matching uuid
So '0' :-((
Suppose that error isn't good either.
Should I downgrade to an earlier version of libvirt?
Please try. My guess is that this is a libvirt bug added by
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=0211fd6e04cdc402da20818df54299c6ded3d3cb
in libvirt 1.0.1. More authoritative answer is expected by those added
to the CC line.
Right, it's the regression introduced by 0211fd6e04, the new defined
network is not marked as persistent, and it's removed from the internal
maintained list by net.destroy(), that's why the error comes
(no network with matching uuid).
Went back to libvirt-0.10. from the danken repo and now it works. Will
reinstall st01 in the same way as a test.
Thanks for the help and have a nice X-mas.
Re-installed two other hosts in the same manner using libvirt-0.10.1-2
from the danken repo and both work.
Will keep on eye on libvirt to see when this is fixed and then try an
upgrade.
Thanks,
Joop
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] tagged vs untagged and sharing the interface
On 12/27/12 2:57 PM, Jeff Bailey bai...@cs.kent.edu wrote: On 12/27/2012 3:01 PM, Jonathan Horne wrote: if someone could help me confirm, but it appear that i cannot co-populate tagged vlan on the same interface as ovirtmgmt? You can but you need to edit the ovirtmgmt network to make it tagged before adding a cluster to the datacenter. It tells me cannot edit management network. for me it would really be better if i can share these 2 on same interface, but if i can't ill just have to live with it. can any one confirm this? thanks, jonathan This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] tagged vs untagged and sharing the interface
On 12/27/2012 6:10 PM, Jonathan Horne wrote: On 12/27/12 2:57 PM, Jeff Bailey bai...@cs.kent.edu wrote: On 12/27/2012 3:01 PM, Jonathan Horne wrote: if someone could help me confirm, but it appear that i cannot co-populate tagged vlan on the same interface as ovirtmgmt? You can but you need to edit the ovirtmgmt network to make it tagged before adding a cluster to the datacenter. It tells me cannot edit management network. If there is already a cluster attached to the datacenter then you can't edit the ovirtmgmt network. You may be able to create another temporary datecenter, move your cluster, edit the network and then move the cluster back. If you edit the network before adding a cluster and hosts then it's easier. I'm not sure you'll be able to move the cluster though. I haven't tried that. If you can't then you'll probably have to remove the hosts and cluster and add them back afterwards. There has been recent discussion about improving this situation so in the future this may not be a problem. for me it would really be better if i can share these 2 on same interface, but if i can't ill just have to live with it. can any one confirm this? thanks, jonathan This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
