Re: [vdsm] creating ovirtmgmt bridge using tagged vlans
Normally I do:
ipython
from vdsm import vdscli
connection = vdscli.connect()
connection.setupNetworks(...)
Now you can check out configNetwork.py:setupNetworks and call it
according to its signature. No need to guess how the CLI works...
- Original Message -
>
>
> - Original Message -
> > From: "Sandro Bonazzola"
> > To: "VDSM Project Development"
> > Cc: "Antoni Segura Puimedon"
> > Sent: Wednesday, March 19, 2014 12:54:45 PM
> > Subject: creating ovirtmgmt bridge using tagged vlans
> >
> > Hi,
> > I'm working on: Bug 1072027 - hosted-engine setup fails when using VLAN
> > tagged interfaces
> >
> > Provided the following caps:
> >
> > # vdsClient -s localhost getVdsHardwareInfo
> > systemFamily = 'Not Specified'
> > systemManufacturer = 'Dell Inc.'
> > systemProductName = 'OptiPlex 7010'
> > systemSerialNumber = 'DYC5YX1'
> > systemUUID = '4C4C4544-0059-4310-8035-C4C04F595831'
> > systemVersion = '01'
> > [root@dellserver network-scripts]# vdsClient -s localhost getVdsCap
> > getVdsCapabilities getVdsCaps
> > [root@dellserver network-scripts]# vdsClient -s localhost getVdsCaps
> > HBAInventory = {'FC': [], 'iSCSI': [{'InitiatorName':
> > 'iqn.1994-05.com.redhat:babababa'}]}
> > ISCSIInitiatorName = 'iqn.1994-05.com.redhat:babababa'
> > bondings = {'bond0': {'addr': '',
> > 'cfg': {},
> > 'hwaddr': '5a:46:b1:db:ec:9b',
> > 'ipv6addrs': [],
> > 'mtu': '1500',
> > 'netmask': '',
> > 'slaves': []}}
> > bridges = {';vdsmdummy;': {'addr': '',
> >'cfg': {},
> >'gateway': '',
> >'ipv6addrs':
> > ['fe80::8c8a:edff:fe92:b332/64'],
> >'ipv6gateway': '::',
> >'mtu': '1500',
> >'netmask': '',
> >'ports': [],
> >'stp': 'off'}}
> > clusterLevels = ['3.0', '3.1', '3.2', '3.3', '3.4']
> > cpuCores = '4'
> > cpuFlags =
> > 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,ida,arat,epb,xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,fsgsbase,smep,erms,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_Westmere,model_n270,model_SandyBridge'
> > cpuModel = 'Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz'
> > cpuSockets = '1'
> > cpuSpeed = '1864.156'
> > cpuThreads = '8'
> > emulatedMachines = ['pc',
> > 'pc-q35-1.4',
> > 'pc-q35-1.5',
> > 'q35',
> > 'isapc',
> > 'pc-0.10',
> > 'pc-0.11',
> > 'pc-0.12',
> > 'pc-0.13',
> > 'pc-0.14',
> > 'pc-0.15',
> > 'pc-1.0',
> > 'pc-1.1',
> > 'pc-1.2',
> > 'pc-1.3',
> > 'pc-i440fx-1.4',
> > 'pc-i440fx-1.5',
> > 'none']
> > guestOverhead = '65'
> > hooks = {}
> > kvmEnabled = 'true'
> > lastClient = '127.0.0.1'
> > lastClientIface = 'lo'
> > management_ip = '0.0.0.0'
> > memSize = '15936'
> > netConfigDirty = 'False'
> > networks = {}
> > nics = {'em1': {'addr': '192.168.1.105',
> > 'cfg': {'DEVICE': 'em1',
> > 'HWADDR': 'b8:ca:3a:76:9a:43',
> > 'MTU': '1500',
> > 'ONBOOT': 'yes'},
> > 'hwaddr': 'b8:ca:3a:76:9a:43',
> > 'ipv6addrs': ['fe80::baca:3aff:fe76:9a43/64'],
> > 'mtu': '1500',
> > 'netmask': '255.255.255.0',
> > 'speed': 1000}}
> > operatingSystem = {'name': 'Fedora', 'release': '8', 'version': '19'}
> > packages2 = {'kernel': {'buildtime': 1394207804.0,
> > 'release': '100.fc19.x86_64',
> > 'version': '3.13.6'},
> > 'libvirt': {'buildtime': 1387094943,
> > 'release': '1.fc19',
> > 'version': '1.1.3.2'},
> > 'mom': {'buildtime': 1391183561, 'release': '1.fc19',
> > 'version': '0.4.0'},
> >
Re: [vdsm] Smarter network_setup hooks
Mid-thread summary: First some terminology so we're all on the same page: 'request' - The setupNetworks that just arrived 'running config' - If unified persistence is being used - All networking on the host as VDSM sees it 'expected' - If unified persistence is being used - The running config after the effects of the request, but before the hook is ran I think we all agree that we have to expose the 'request' to the hook. However, there's two different approaches: 1) Allow the hook to rewrite parts of the request (For example, if two networks were sent, and the hook handled one of them, it could then delete that network from the request, so VDSM will only continue to configure the 2nd network). 2) Toni's idea with marking devices as hook-configured. So if a network is over a bridge over a VLAN over a bond over three NICs, hooks could configure only the NICs (For example) and VDSM would configure the rest, whereas the first idea means that the hook would have to configure the entire network (Bridge, VLANs, bonds, and all 3 NICs) and then remove that network from the request. The disadvantage of this method is that it would be harder to implement, and have references to the hooks flag throughout all of VDSM. Then there's the matter of IF to expose the 'running config' and 'expected'. My main argument is that it's very easy to expose to the hooks (But then why not expose other 'random' data that is easy for VDSM to calculate?), and that we don't understand all usages for the setupNetworks hooks. I'd rather we expose too much information than not enough and screw over hook writers. Either way, let's get some votes in a timely manner so we could manage to implement this for 3.4. Assaf Muller, Cloud Networking Engineer Red Hat - Original Message - From: "Adam Litke" To: "Miguel Angel" Cc: dsull...@redhat.com, a...@ovirt.org, vdsm-de...@fedorahosted.org Sent: Monday, January 6, 2014 3:32:07 PM Subject: Re: [vdsm] Smarter network_setup hooks On 04/01/14 20:08 +0100, Miguel Angel wrote: >Hi Adam > >Thanks for the feedback > >2014/1/3 Adam Litke > >> On 03/01/14 12:20 +, Dan Kenigsberg wrote: >> >>> Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the >>> implementation of setupNetworks in Vdsm: two hook points where added: >>> before and after the setupNetworks verb takes place. >>> [] >> >> Seems like a logical thing to do. What specific mechanism do you >> suggest for passing the JSON strings to the hook script? If passed as >> arguments to the hook script we would need to consider shell escaping >> and argv length restrictions. >> >> As for the libvirt domain xml we pass to other hooks, we write a temporary >file >and we set an environment variable pointing to it before calling the script > > >> What about writing these out to a special file and adding a new >> getContext() call to the hooking module. A script that is unconcerned >> with the context would not require any changes. But a script that >> wants access would simply do: >> >>ctx = hooking.getContext() >> >> and ctx would be the contents of the special file already decoded into >> a native Python object for easy consumption. This could easily be >> extended to any hook which may want to provide some context to >> implementors. >> > >That would be nice, so scripts written in python wouldn't need to look for, >and parse >the file. > >This is an example of a simple hook: > >http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py (look >inside the ValidatesHook decorator) > > >It'd be quite simplified. We would also need a "setContext()..." to update >context with changes. Yeah seems reasonable. Then hook scripts can become much simpler and easier to read and write: ctx = hooking.getContext() ctx['foo'] = 'bar' hooking.setContext(ctx) > > >> >> One more question comes to mind: Are there any pieces of information >> that we would need to redact from the context (passwords or other >> sensitive information)? >> >> >I think there is no sensitive information as far as I know. > >Greetings, >Miguel Ángel. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] gluster verbs are broken due to missing updateTimestamp()
master: http://gerrit.ovirt.org/#/c/23044/ ovirt-3.3: http://gerrit.ovirt.org/#/c/23045/ Assaf Muller, Cloud Networking Engineer Red Hat - Original Message - From: "Assaf Muller" To: "Balamurugan Arumugam" , "Dan Kenigsberg" Cc: "VDSM Project Development" Sent: Tuesday, January 7, 2014 4:04:18 PM Subject: Re: [vdsm] gluster verbs are broken due to missing updateTimestamp() This regression was introduced by (my) patch: http://gerrit.ovirt.org/#/c/22837/3/vdsm/BindingXMLRPC.py Which was recently merged to master. You can see how updateTimestamp() is implemented at: BindingXMLRPC.py, line 83. (A dummy/blank implementation would not work). There's several approaches to solve this, I think the correct way would be to make updateTimestamp a class method of the BindingXMLRPC class, and change the calls from im_self to BindingXMLRPC.updateTimestamp. That way it doesn't matter which method wrapApiMethod wraps, or what class defined the method, it'll 'just work'. I'll send a patch ASAP. Assaf Muller, Cloud Networking Engineer Red Hat - Original Message - From: "Balamurugan Arumugam" To: "Nir Soffer" Cc: "VDSM Project Development" Sent: Tuesday, January 7, 2014 3:40:53 PM Subject: [vdsm] gluster verbs are broken due to missing updateTimestamp() Hi, I see vdsm master is broken wrt gluster verbs. When I run any gluster verbs, it errors out Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 941, in wrapper f.im_self.updateTimestamp() AttributeError: 'GlusterApi' object has no attribute 'updateTimestamp' I added a dummy updateTimestamp() in gluster.api.GlusterApi which resolves the issue, but I am not sure whether its correct or not. Could you provide some info on updateTimestamp() and whether its applicable to gluster module? Regards, Bala ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] gluster verbs are broken due to missing updateTimestamp()
This regression was introduced by (my) patch: http://gerrit.ovirt.org/#/c/22837/3/vdsm/BindingXMLRPC.py Which was recently merged to master. You can see how updateTimestamp() is implemented at: BindingXMLRPC.py, line 83. (A dummy/blank implementation would not work). There's several approaches to solve this, I think the correct way would be to make updateTimestamp a class method of the BindingXMLRPC class, and change the calls from im_self to BindingXMLRPC.updateTimestamp. That way it doesn't matter which method wrapApiMethod wraps, or what class defined the method, it'll 'just work'. I'll send a patch ASAP. Assaf Muller, Cloud Networking Engineer Red Hat - Original Message - From: "Balamurugan Arumugam" To: "Nir Soffer" Cc: "VDSM Project Development" Sent: Tuesday, January 7, 2014 3:40:53 PM Subject: [vdsm] gluster verbs are broken due to missing updateTimestamp() Hi, I see vdsm master is broken wrt gluster verbs. When I run any gluster verbs, it errors out Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 941, in wrapper f.im_self.updateTimestamp() AttributeError: 'GlusterApi' object has no attribute 'updateTimestamp' I added a dummy updateTimestamp() in gluster.api.GlusterApi which resolves the issue, but I am not sure whether its correct or not. Could you provide some info on updateTimestamp() and whether its applicable to gluster module? Regards, Bala ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] before_device_migrate_source not being called after http://gerrit.ovirt.org/#/c/14203/
Master branch: http://gerrit.ovirt.org/#/c/23006/ ovirt-3.3 branch: http://gerrit.ovirt.org/#/c/23012/ Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1047646 Thanks Vinzenz! Assaf Muller, Cloud Networking Engineer Red Hat - Original Message - From: "Yaniv Bronheim" To: "Assaf Muller" Cc: "vdsm-devel" Sent: Monday, January 6, 2014 11:22:29 AM Subject: Re: [vdsm] before_device_migrate_source not being called after http://gerrit.ovirt.org/#/c/14203/ please open a bug on it to follow the issue thanks - Original Message - > From: "Assaf Muller" > To: "vdsm-devel" > Sent: Sunday, January 5, 2014 4:16:36 PM > Subject: [vdsm] before_device_migrate_source not being called after > http://gerrit.ovirt.org/#/c/14203/ > > While reviewing some unrelated issue I noticed that > before_device_migrate_source is no longer > being called. This would be an oVirt 3.3 regression for hook users. If we > could fix this by > 3.3 downstream release it'd be a win as well. Vinzenz are you available to > fix this in time? > If not please alert early and I'll help out. > > > Assaf Muller, Cloud Networking Engineer > Red Hat > ___ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] before_device_migrate_source not being called after http://gerrit.ovirt.org/#/c/14203/
While reviewing some unrelated issue I noticed that before_device_migrate_source is no longer being called. This would be an oVirt 3.3 regression for hook users. If we could fix this by 3.3 downstream release it'd be a win as well. Vinzenz are you available to fix this in time? If not please alert early and I'll help out. Assaf Muller, Cloud Networking Engineer Red Hat ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Smarter network_setup hooks
Whichever way we decide to do this, I think the important bit is documentation - We have to make sure to update the oVirt wiki hooks pages. If users aren't aware of how to retrieve the networking config then we might as well not implement it. That being said, I'd expose three dictionaries: What's currently configure, the current request, as well as the proposed end result. It's easy to add and I see how it would be useful to hook writers. And just to state the obvious, just like how traditional hooks can change the VM or device XML, the hook should be able to rewrite the current request contents. For example, if a user would like to take over host networking configuration, he could just write a before_setup_networks hook that would configure networking however he wants, then writes the empty dictionary to the current request, meaning that VDSM wouldn't do anything further with the current setup networks request. Assaf Muller, Cloud Networking Engineer Red Hat - Original Message - From: "Miguel Angel" To: "Adam Litke" Cc: dsull...@redhat.com, a...@ovirt.org, vdsm-de...@fedorahosted.org Sent: Saturday, January 4, 2014 9:08:17 PM Subject: Re: [vdsm] Smarter network_setup hooks Hi Adam Thanks for the feedback 2014/1/3 Adam Litke < ali...@redhat.com > On 03/01/14 12:20 +, Dan Kenigsberg wrote: Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the implementation of setupNetworks in Vdsm: two hook points where added: before and after the setupNetworks verb takes place. [] Seems like a logical thing to do. What specific mechanism do you suggest for passing the JSON strings to the hook script? If passed as arguments to the hook script we would need to consider shell escaping and argv length restrictions. As for the libvirt domain xml we pass to other hooks, we write a temporary file and we set an environment variable pointing to it before calling the script What about writing these out to a special file and adding a new getContext() call to the hooking module. A script that is unconcerned with the context would not require any changes. But a script that wants access would simply do: ctx = hooking.getContext() and ctx would be the contents of the special file already decoded into a native Python object for easy consumption. This could easily be extended to any hook which may want to provide some context to implementors. That would be nice, so scripts written in python wouldn't need to look for, and parse the file. This is an example of a simple hook: http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py (look inside the ValidatesHook decorator) It'd be quite simplified. We would also need a "setContext()..." to update context with changes. One more question comes to mind: Are there any pieces of information that we would need to redact from the context (passwords or other sensitive information)? I think there is no sensitive information as far as I know. Greetings, Miguel Ángel. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Latest master fails to start due to logging
That has to be it. However, unless there's a bug in the way I add/remove handlers in upgrade.py (Which there probably is or this error doesn't make any sense) then no VDSM code ever outputs to upgrade.log apart from upgrade.py. I looked at the code again and it seems correct. I also failed to reproduce the error no matter which order I tried to start things up. We could solve the error without understanding the issue (Which is no fun) and just make sure that upgrade.log is created with vdsm:kvm permissions. Assaf Muller, Cloud Networking Engineer Red Hat - Original Message - From: "Yaniv Bronheim" To: "Assaf Muller" Cc: "Antoni Segura Puimedon" , "vdsm-devel" Sent: Sunday, December 8, 2013 2:28:28 AM Subject: Re: [vdsm] Latest master fails to start due to logging its probably because when you run first the new vdsm-tool command as root, you create the upgrade.log as root, and when somewhere in vdsm code you call it again , it fails to open the log file as vdsm user. could be? - Original Message - > From: "Assaf Muller" > To: "Antoni Segura Puimedon" > Cc: "vdsm-devel" > Sent: Wednesday, December 4, 2013 1:59:20 PM > Subject: Re: [vdsm] Latest master fails to start due to logging > > I'm unable to reproduce the issue at this time. > > > Assaf Muller, Cloud Networking Engineer > Red Hat > > - Original Message - > From: "Assaf Muller" > To: "Antoni Segura Puimedon" > Cc: "vdsm-devel" > Sent: Wednesday, December 4, 2013 12:12:32 PM > Subject: Re: [vdsm] Latest master fails to start due to logging > > It's due to recent unified net persistence patches that were merged > yesterday. > > If you change the persistence model to ifcfg it shouldn't happen. > Alternatively > you can: > touch /var/lib/vdsm/upgrade/UnifiedPersistence > > And the upgrade won't run even if you're using unified persistence and VDSM > will boot. > > I'll look into why this is happening and send a patch today. > > Assaf Muller, Cloud Networking Engineer > Red Hat > > - Original Message - > From: "Antoni Segura Puimedon" > To: "vdsm-devel" > Sent: Wednesday, December 4, 2013 12:05:20 PM > Subject: [vdsm] Latest master fails to start due to logging > > Hi List, > > I just upgraded my testing vdsm to the new master and vdsmd fails to go > up due to: > > [vdsm@nx01]~% /usr/share/vdsm/vdsm > Traceback (most recent call last): > File "/usr/share/vdsm/vdsm", line 175, in > run(**argDict) > File "/usr/share/vdsm/vdsm", line 67, in run > lconfig.fileConfig(loggerConfFile) > File "/usr/lib64/python2.7/logging/config.py", line 78, in fileConfig > handlers = _install_handlers(cp, formatters) > File "/usr/lib64/python2.7/logging/config.py", line 156, in > _install_handlers > h = klass(*args) > File "/usr/lib64/python2.7/logging/handlers.py", line 392, in __init__ > logging.FileHandler.__init__(self, filename, mode, encoding, delay) > File "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__ > StreamHandler.__init__(self, self._open()) > File "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open > stream = open(self.baseFilename, self.mode) > IOError: [Errno 13] Permission denied: '/var/log/vdsm/upgrade.log' > > I'd appreciate it if somebody could point me if there is a known patch for > that > > Best, > > Toni > ___ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > ___ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > ___ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Latest master fails to start due to logging
I'm unable to reproduce the issue at this time. Assaf Muller, Cloud Networking Engineer Red Hat - Original Message - From: "Assaf Muller" To: "Antoni Segura Puimedon" Cc: "vdsm-devel" Sent: Wednesday, December 4, 2013 12:12:32 PM Subject: Re: [vdsm] Latest master fails to start due to logging It's due to recent unified net persistence patches that were merged yesterday. If you change the persistence model to ifcfg it shouldn't happen. Alternatively you can: touch /var/lib/vdsm/upgrade/UnifiedPersistence And the upgrade won't run even if you're using unified persistence and VDSM will boot. I'll look into why this is happening and send a patch today. Assaf Muller, Cloud Networking Engineer Red Hat - Original Message - From: "Antoni Segura Puimedon" To: "vdsm-devel" Sent: Wednesday, December 4, 2013 12:05:20 PM Subject: [vdsm] Latest master fails to start due to logging Hi List, I just upgraded my testing vdsm to the new master and vdsmd fails to go up due to: [vdsm@nx01]~% /usr/share/vdsm/vdsm Traceback (most recent call last): File "/usr/share/vdsm/vdsm", line 175, in run(**argDict) File "/usr/share/vdsm/vdsm", line 67, in run lconfig.fileConfig(loggerConfFile) File "/usr/lib64/python2.7/logging/config.py", line 78, in fileConfig handlers = _install_handlers(cp, formatters) File "/usr/lib64/python2.7/logging/config.py", line 156, in _install_handlers h = klass(*args) File "/usr/lib64/python2.7/logging/handlers.py", line 392, in __init__ logging.FileHandler.__init__(self, filename, mode, encoding, delay) File "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__ StreamHandler.__init__(self, self._open()) File "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open stream = open(self.baseFilename, self.mode) IOError: [Errno 13] Permission denied: '/var/log/vdsm/upgrade.log' I'd appreciate it if somebody could point me if there is a known patch for that Best, Toni ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Latest master fails to start due to logging
It's due to recent unified net persistence patches that were merged yesterday. If you change the persistence model to ifcfg it shouldn't happen. Alternatively you can: touch /var/lib/vdsm/upgrade/UnifiedPersistence And the upgrade won't run even if you're using unified persistence and VDSM will boot. I'll look into why this is happening and send a patch today. Assaf Muller, Cloud Networking Engineer Red Hat - Original Message - From: "Antoni Segura Puimedon" To: "vdsm-devel" Sent: Wednesday, December 4, 2013 12:05:20 PM Subject: [vdsm] Latest master fails to start due to logging Hi List, I just upgraded my testing vdsm to the new master and vdsmd fails to go up due to: [vdsm@nx01]~% /usr/share/vdsm/vdsm Traceback (most recent call last): File "/usr/share/vdsm/vdsm", line 175, in run(**argDict) File "/usr/share/vdsm/vdsm", line 67, in run lconfig.fileConfig(loggerConfFile) File "/usr/lib64/python2.7/logging/config.py", line 78, in fileConfig handlers = _install_handlers(cp, formatters) File "/usr/lib64/python2.7/logging/config.py", line 156, in _install_handlers h = klass(*args) File "/usr/lib64/python2.7/logging/handlers.py", line 392, in __init__ logging.FileHandler.__init__(self, filename, mode, encoding, delay) File "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__ StreamHandler.__init__(self, self._open()) File "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open stream = open(self.baseFilename, self.mode) IOError: [Errno 13] Permission denied: '/var/log/vdsm/upgrade.log' I'd appreciate it if somebody could point me if there is a known patch for that Best, Toni ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Upgrade mechanism
While implementing a new form of network configuration persistence I needed a way to run 'upgrade code'. That is, I need the ability to run a piece of code exactly once, on the first boot of VDSM. My use case is related to unified network persistence - We intend to persist network information in a new format, and on the first run of a new VDSM that contains unified network persistence code, it needs to inspect the kernel state and construct the data in the new format. From then on, it will be persisted and updated when the setupNetworks verb is received. The upgrade code, then, needs to run only once. Instead of implementing a unique and custom solution I thought to introduce a very simple and flexible upgrade mechanism which suits my needs. http://gerrit.ovirt.org/#/c/17726/ And the following patch is the actual upgrade code, which demonstrates how the upgrade mechanism is used: http://gerrit.ovirt.org/#/c/18425/ Clarification: This upgrade mechanism is not related to yum upgrade in any way. Infra guys (And everyone else) - Any feedback is welcome. Thanks! ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsClient networking (addNetwork with existing bond)
Here you go:
vdsClient -s 0 setupNetworks
networks='{rhevm:{bonding:bond2,bootproto:dhcp,bridged:True}}'
bondings='{bond2:{nics:eth1+eth2}}'
- Original Message -
From: "Sandro Bonazzola"
To: "VDSM Project Development"
Sent: Thursday, August 22, 2013 9:44:06 AM
Subject: [vdsm] vdsClient networking (addNetwork with existing bond)
Hi,
I'm trying to fix https://bugzilla.redhat.com/999577 which in short is
failing to create bridge specifying a bond interface as nic using vdsClient.
The failing command line is:
'/usr/bin/vdsClient', '-s', 'localhost', 'addNetwork', 'bridge=rhevm', 'vlan=',
'bond=',
'nics=bond2', 'force=False', 'bridged=True', 'BOOTPROTO=dhcp', 'ONBOOT=yes',
'blockingdhcp=true'
I suppose that 'nics=bond2' and 'bond=' are wrong.
I'm searching for a man page or something like that for understanding how to
prepare the command line without success.
http://www.ovirt.org/VdsClient is outdated and says anything about networking.
I've seen in http://www.ovirt.org/Vdsm_Network that using a bond should be
supported but for the supported topologies
there are no command line examples.
For:
bridge1 --- bond --- nic1
\
-- nic2
I suppose that the command line should have 'bond=bond' 'nics=nic1,nic2' is
this right?
If the bond already exists is it enough specifying 'bond=bond', 'nics=' ?
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Jenkins job to run networking functional tests
+1 Giuseppe is our go to guy as far as networking tests go! - Original Message - From: "Sandro Bonazzola" To: "Eyal Edri" Cc: "engine-devel" , "vdsm-devel" , "infra" Sent: Monday, August 19, 2013 2:20:36 PM Subject: Re: [vdsm] Jenkins job to run networking functional tests Il 19/08/2013 11:26, Eyal Edri ha scritto: > [adding devel lists] > > Usually to get power user privileges you need get +1 community (mostly > relevant people in your team/project). > saying you're familiar with jenkins and the project and is cabaple of adding > jobs to the project. > > I personally give +1 since i know you're contribution and experience. > > Eyal. +1 from me too. Sandro > > - Original Message - >> From: "Giuseppe Vallarelli" >> To: "infra" >> Sent: Monday, August 19, 2013 10:19:46 AM >> Subject: Jenkins job to run networking functional tests >> >> Hello everybody, following the previous discussion with Eyal, >> I need to get rights in order to create a jenkins job to >> achieve what stated in the subject. >> >> Is it the right place for such request? >> >> Cheers, Giuseppe >> >> - Forwarded Message - >> | From: "Eyal Edri" >> | To: "Giuseppe Vallarelli" >> | Cc: "infra" >> | Sent: Sunday, August 18, 2013 2:06:22 PM >> | Subject: Re: running network functional tests >> | >> | Hi, >> | >> | Usually in these cases when a new job is requested to a specific >> | project/component, >> | A 'power user' for the relevant team (in your case network), is given >> | privileges on the Jenkins machine >> | to add any job required. >> | >> | I would propose the following: >> | 1. request power user access to jenkins.ovirt.org (if you don't already >> | have) >> | 2. add a new job with your functional test per commit (not per patch for >> | starts) >> | any infra member can assist you with the labels for slaves / os /etc... >> | 3. once that job is running properly, you can contact infra to assist in >> | converting it to a per-patch job >> | with the topic / field verification logic done. >> | 4. not sure if this is relevant to your tests, but all existing jenkins >> | slaves are VMs and not bare-metal. >> | >> | i hope this helps. >> | >> | Eyal. >> | >> | - Original Message - >> | > From: "Giuseppe Vallarelli" >> | > To: "infra" >> | > Sent: Friday, August 16, 2013 12:28:43 PM >> | > Subject: Fwd: running network functional tests >> | > >> | > - Forwarded Message - >> | > | From: "Giuseppe Vallarelli" >> | > | To: "infra" >> | > | Cc: "David Caro Estevez" >> | > | Sent: Monday, August 12, 2013 10:58:04 AM >> | > | Subject: running network functional tests >> | > | >> | > | Hello everbody! >> | > | Just recently we added networking functional tests and we would like >> | > | to have them running when we submit patches network related, i.e. >> | > | going to affect network modules. Displaying success or failure >> | > | as it happens with the current unittests. >> | > | >> | > | Requirements/ideas: >> | > | >> | > | - OS Fedora 19/RHEL6.4 should not matter. >> | > | >> | > | - Kernel module used: bonding, dummy. >> | > | >> | > | - No more than one 'instance' of networkTests should run >> | > | on a specific host, simply because we use some global >> | > | constants to identify network name vlan id and so on. >> | > | >> | > | - Ideally we can use a previously proposed idea of commit tag >> | > | where for example @networking is provided in the commit msg >> | > | title to identify the need of running also the network >> | > | functional tests. >> | > | >> | > | - We should be able to run at the same time functional networking >> | > | tests and unit tests - I don't expect any conflicts. >> | > | >> | > | Would be cool to have a test run before -1s all networking patches >> | > | in case of problems :-) >> | > | >> | > | Let me know if more information are needed. >> | > | >> | > | >> | > | Cheers, Giuseppe >> | > >> | > Is there any update on the subject? >> | > >> | > Any estimate to have functional network tests running? >> | > I mind that we can run network functional tests upstream >> | > that will speed up our workflow and possibly decrease the >> | > regressions. >> | > >> | > Thanks Giuseppe >> | > ___ >> | > Infra mailing list >> | > in...@ovirt.org >> | > http://lists.ovirt.org/mailman/listinfo/infra >> | > >> | >> ___ >> Infra mailing list >> in...@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/infra >> > ___ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https:/
Re: [vdsm] Migration regression on master
* We still need to see the vmCreate command used to learn more about the issue * We can always implement a hack that checks if the alias attribute exists. However, there is probably a deeper issue at hand and this is a good opportunity to find and solve it * Dan has a theory that the issue is with migrating a VM from a 3.0 VDSM version host to a 3.2 host. Perhaps the balloon device isn't created properly at the source host From: "Dan Kenigsberg" To: "Peter V. Saveliev" Cc: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, May 29, 2013 4:41:24 PM Subject: Re: [vdsm] Migration regression on master On Wed, May 29, 2013 at 02:13:02PM +0200, Peter V. Saveliev wrote: > On 05/29/2013 07:17 AM, Dan Kenigsberg wrote: > >On Tue, May 28, 2013 at 11:54:45AM -0400, Giuseppe Vallarelli wrote: > >> | ----- Original Message - > >>| | From: "Assaf Muller" > >>| | To: "Michal Skrivanek" > >>| | Cc: "vdsm-devel@lists.fedorahosted.org Development" > >>| | > >>| | Sent: Thursday, May 23, 2013 2:12:47 PM > >>| | Subject: Re: [vdsm] Migration regression on master > >>| | > >>| | As you can see in a previous patch set I checked if the alias attribute > >>| | exists instead of assuming it exists. > >>| | I then changed my mind with Dan's blessing, and decided to assume it > >>does > >>| | exist, exactly for cases like this. > >>| | Even if we check if the alias exists, what do we do if we find out it > >>| | doesn't? We're at a problem and need to understand why the alias > >>doesn't > >>| | exist because it should - For all devices. > >>| | > >>| | We definitely need to deal with this issue - Can you provide the domxml > >>of > >>| | the VM during creation, and during migration? > >> > >>Hi Assaf, Peter today has reproduced the same error and provided me > >>the output log, you can find it here: > >>http://etherpad.ovirt.org/p/migration-errors > > > >Would you add the original vmCreate line, and domxml, that was used to > >create the VM at the source host? > > http://pastebin.test.redhat.com/17 > http://pastebin.test.redhat.com/16 That's an internal pastebin instance. Could you simply inline the answer? Hyperlinks makes a casual reader of the mailing list not understand what's going on. Note that we need vmCreate command, the response is less interesting, thow seeing the whole vdsm thread would not harm. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Migration regression on master
As you can see in a previous patch set I checked if the alias attribute exists instead of assuming it exists. I then changed my mind with Dan's blessing, and decided to assume it does exist, exactly for cases like this. Even if we check if the alias exists, what do we do if we find out it doesn't? We're at a problem and need to understand why the alias doesn't exist because it should - For all devices. We definitely need to deal with this issue - Can you provide the domxml of the VM during creation, and during migration? - Original Message - From: "Michal Skrivanek" To: "Vinzenz Feenstra" , "Assaf Muller" Cc: "vdsm-devel@lists.fedorahosted.org Development" , "Dan Kenigsberg" Sent: Wednesday, May 22, 2013 3:56:22 PM Subject: Re: [vdsm] Migration regression on master On May 22, 2013, at 10:14 , Vinzenz Feenstra wrote: > Hi, > > During the verification of the refactoring in VDSM (libvirtvm + vm == vm) we > have encountered some issue. > There seems to be a regression on master branch regarding device aliases. > > On the target machine _updateDevicesDomxmlCache accesses dev.alias without > the attribute being present. > > This happens to happen at least on balloon devices. > I am not sure why we do have this, however it is reproducible and I am not > sure why we do this now. > > I know it has been introduced by http://gerrit.ovirt.org/#/c/13876 and it's > actually in the commit message that we'd fail. :-) you mean: * We now crash horribly if an alias was not found for a device when updating devices domxml cache after migrating > Which is the case... So can somebody please enlighten me and tell me if this > is a configuration issue of the VM or if this really a regression. not all devices have alias so I think this is indeed a regression > It's possible that the tests aren't properly configured, however that would > from my understanding mean that we potentially will run into troubles during > migrations from 3.2 -> 3.3 vdsm. > > PS: > This kind of blocks a bit the refactoring verification :/ > > -- > Regards, > > Vinzenz Feenstra | Senior Software Engineer > RedHat Engineering Virtualization R & D > Phone: +420 532 294 625 > IRC: vfeenstr or evilissimo > > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > > ___ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Per device custom properties
Hi all, Right now we have the ability to define VM-wide properties that may be used by hooks. It is time we have the same functionality on a device basis: http://www.ovirt.org/Features/Device_Custom_Properties For example: If the VM has 2 disks called disk1 and disk2, and two NICs called nic1 and nic2, and the admin (From the engine) added a custom property qos: 0.5 for nic1 and a custom property defrag: None for disk2. When the VM is started we'll run a hook for nic1 with its XML and qos: 0.5 added as an environment variable, and a hook for disk2 with its XML and defrag: None. When a device is hot plugged and it has custom properties we'll run that hook as well. Implementation-wise, hot plug/unplug for disks and NICs is dead simple - vmCreate is more problematic: If the user set a custom property called 'qos: 0.8' for nic3, I'd want it exposed as an environment variable called 'qos' for hot plug nic hooks, but for vmCreate I'd like to prefix the nic's alias. However, when vmCreate is called we don't have the aliases for NICs and disks. The proposed solution is to create a new hook point called something like: 'before_device_creation' that will be called before vmCreate. We'll then call that hook specifically for devices that contains custom properties, as described in the second paragraph of this mail. I would love to hear smarter ideas before I move forward. Thanks! ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
