<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">On Thu, Nov 15, 2012 at 1:11 AM, Igor Lvovsky </span><span dir="ltr" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><<a href="mailto:ilvovsky@redhat.com" target="_blank" style="color:rgb(17,85,204)">ilvovsky@redhat.com</a>></span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"> wrote:</span><br style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<div class="gmail_quote" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Alan,<div class="im" style="color:rgb(80,0,80)"><br><div><br>If I understand you correctly, you try to add a new VM-VLANed network (sandbox)</div>to interface em1 that already has another VM network (ovirtmgmt).<br>
<br>
If so, this operation is not permited. You can't attach VM-VLANed network and<br>VM-nonVLANed network to same interface.<br></div></blockquote><div><br></div><div>Good to know. I'll start working on another solution that might work once I get around the blocking bug (more on this in response to Roy shortly). Is there a way to convert the ovirtmgmt network to VLAN'd? </div>
<div><br></div><div>Also, while I have your attention, I expect I will have to enable each VLAN on each host's port of the connected switch, which means I have to set each port with multiple VLANs to trunk mode. Is that right?</div>
<div class="im" style="color:rgb(80,0,80)"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
To be sure that this is a case, I need to know your vdsm version<br>and vdsm log will be good as well<br></blockquote><div><br></div></div><div>There is nothing in the log with that time stamp (as Roy has observed, it is not getting that far), but here are the versions just FYI:</div>
<div><div>[root@cloudhost01 ~]# rpm -qa | fgrep vdsm</div><div>vdsm-python-4.10.0-0.44.14.el6.x86_64</div><div>vdsm-xmlrpc-4.10.0-0.44.14.el6.noarch</div><div>vdsm-4.10.0-0.44.14.el6.x86_64</div><div>vdsm-cli-4.10.0-0.44.14.el6.noarch</div>
<div>vdsm-gluster-4.10.0-0.44.14.el6.noarch</div></div></div>