12:54 p.m.
Hi,
Im very new to virtualization on Linux, wanting to kick the tires
some, and am wondering where best to go next.
Right now, ive done the 'all in one install' of ovirt 3.4 on a single
fedora 19 machine. Its a desktop with a wifi network interface, and im
trying to set up the kvm hypervisor in combination with macvtap. Any
pointers to docs on what best to do next is appreciated. Im currently
trying to make sense of this:
http://www.ovirt.org/Quick_Start_Guide
Also, as far as I can tell, there seems to be an issue with the
detection of my wireless wifi network interface 'wlp2s0' as it doesnt
seem to show up anywhere in the interface. I can attach the
'ovirtmgmt' network to my standard wired ethernet interface 'p2p2',
but that device is not in use on the machine and it is disconnected
from the network.
Reading about linux virt and issues with bridging with wifi NIC's on
the web made me, perhaps incorrectly here, assume that a wifi nic
might be an issue, so thats where the idea to use macvtap came from.
Manual setup of macvtap seems to work, as i can do this without issues
on a root prompt on the same machine:
ip link add link wlp2s0 name macvtap0 type macvtap
ip link set macvtap0 address 1a:46:0b:ca:bc:7b up
ip link show macvtap0
But the wifi interface 'wlp2s0' does not seem to show up in the ovirt
web gui interface.
Im sorry if I sound confusing here, but that may be just because im
really still confused about ovirt.
;)
So any pointers on what to read up on or do next is appreciated,
Thanks,
Regards,
John Smith.
12:32 a.m.
On 05/04/2014 05:54 AM, John Smith wrote:
Hi,
Im very new to virtualization on Linux, wanting to kick the tires
some, and am wondering where best to go next.
Right now, ive done the 'all in one install' of ovirt 3.4 on a single
fedora 19 machine. Its a desktop with a wifi network interface, and im
trying to set up the kvm hypervisor in combination with macvtap. Any
pointers to docs on what best to do next is appreciated. Im currently
trying to make sense of this:
http://www.ovirt.org/Quick_Start_Guide
Also, as far as I can tell, there seems to be an issue with the
detection of my wireless wifi network interface 'wlp2s0' as it doesnt
seem to show up anywhere in the interface. I can attach the
'ovirtmgmt' network to my standard wired ethernet interface 'p2p2',
but that device is not in use on the machine and it is disconnected
from the network.
Reading about linux virt and issues with bridging with wifi NIC's on
the web made me, perhaps incorrectly here, assume that a wifi nic
might be an issue, so thats where the idea to use macvtap came from.
Manual setup of macvtap seems to work, as i can do this without issues
on a root prompt on the same machine:
ip link add link wlp2s0 name macvtap0 type macvtap
ip link set macvtap0 address 1a:46:0b:ca:bc:7b up
ip link show macvtap0
But the wifi interface 'wlp2s0' does not seem to show up in the ovirt
web gui interface.
Im sorry if I sound confusing here, but that may be just because im
really still confused about ovirt.
;)
So any pointers on what to read up on or do next is appreciated,
Thanks,
Regards,
John Smith.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
ovirt is meant to manage your datacenter, so not the best match for
running with a wireless nic i guess.
vdsm may even be filtering it (danken?)
1:49 p.m.
On Sun, May 11, 2014 at 05:32:41PM -0400, Itamar Heim wrote:
On 05/04/2014 05:54 AM, John Smith wrote:
>Hi,
>
>
>Im very new to virtualization on Linux, wanting to kick the tires
>some, and am wondering where best to go next.
>
>Right now, ive done the 'all in one install' of ovirt 3.4 on a single
>fedora 19 machine. Its a desktop with a wifi network interface, and im
>trying to set up the kvm hypervisor in combination with macvtap. Any
>pointers to docs on what best to do next is appreciated. Im currently
>trying to make sense of this:
>http://www.ovirt.org/Quick_Start_Guide
>
>Also, as far as I can tell, there seems to be an issue with the
>detection of my wireless wifi network interface 'wlp2s0' as it doesnt
>seem to show up anywhere in the interface. I can attach the
>'ovirtmgmt' network to my standard wired ethernet interface 'p2p2',
>but that device is not in use on the machine and it is disconnected
>from the network.
>
>Reading about linux virt and issues with bridging with wifi NIC's on
>the web made me, perhaps incorrectly here, assume that a wifi nic
>might be an issue, so thats where the idea to use macvtap came from.
>
>Manual setup of macvtap seems to work, as i can do this without issues
>on a root prompt on the same machine:
>
>ip link add link wlp2s0 name macvtap0 type macvtap
>ip link set macvtap0 address 1a:46:0b:ca:bc:7b up
>ip link show macvtap0
>
>But the wifi interface 'wlp2s0' does not seem to show up in the ovirt
>web gui interface.
>
>Im sorry if I sound confusing here, but that may be just because im
>really still confused about ovirt.
>;)
>
>So any pointers on what to read up on or do next is appreciated,
>
>
>Thanks,
>
>
>Regards,
>
>
>John Smith.
>_______________________________________________
>Users mailing list
>Users(a)ovirt.org
>http://lists.ovirt.org/mailman/listinfo/users
>
ovirt is meant to manage your datacenter, so not the best match for
running with a wireless nic i guess.
vdsm may even be filtering it (danken?)
It is, because oVirt only supports bridge-based VM networks, and Linux
does not allow you to bridge a WiFi nic.
To work around this limitation, you could define a NAT-based network in
libvirt http://libvirt.org/formatnetwork.html#examplesNAT and use it in
oVirt via vdsm-hook-extnet (a bit more about it in
http://developerblog.redhat.com/2014/02/25/extending-rhev-vdsm-hooks/ )
Dan.
6:12 p.m.
On Mon, May 12, 2014 at 12:49 PM, Dan Kenigsberg <danken(a)redhat.com> wrote:
oVirt only supports bridge-based VM networks, and Linux
does not allow you to bridge a WiFi nic.
Which is why I was looking at the option of using 'macvtap' instead,
which does allow you to use a wifi nic:
http://libvirt.org/formatnetwork.html#examplesDirect
http://www.libvirt.org/formatdomain.html#elementsNICSDirect
However, my current knowledge (of libvirt, etc.) is too limited to use
those two links to create a working setup for me, so some more
detailed and/or elaborate instructions and/or documentation would be
appreciated.
It seems to involve the manual creation of xml files, and then feeding
those to virsh in order to change the configuration or something ? Is
there a command i can feed vrish to make it dump the current
configuration in xml, so that maybe i can start to use that as a basis
and hack it up to see what happens ?
Thanks again,
Regards,
John Smith.
6:39 p.m.
On Mon, May 12, 2014 at 05:12:14PM +0200, John Smith wrote:
On Mon, May 12, 2014 at 12:49 PM, Dan Kenigsberg
<danken(a)redhat.com> wrote:
>
> oVirt only supports bridge-based VM networks, and Linux
> does not allow you to bridge a WiFi nic.
>
Which is why I was looking at the option of using 'macvtap' instead,
which does allow you to use a wifi nic:
http://libvirt.org/formatnetwork.html#examplesDirect
http://www.libvirt.org/formatdomain.html#elementsNICSDirect
A big limitation of the macvtap approach is that it would let you
connect only a single VM to your WiFi. Is that fine by you?
However, my current knowledge (of libvirt, etc.) is too limited to use
those two links to create a working setup for me, so some more
detailed and/or elaborate instructions and/or documentation would be
appreciated.
It seems to involve the manual creation of xml files, and then feeding
those to virsh in order to change the configuration or something ? Is
there a command i can feed vrish to make it dump the current
configuration in xml, so that maybe i can start to use that as a basis
and hack it up to see what happens ?
Yes, defining a libvirt network requires using
virsh net-define <xmlfile>
(you may need to pass the not-so-secret vdsm@ovirt/shibboleth password
to tinker with libvirt, which is better done on non-production setup)
virsh net-dumpxml <net-name>
could show you what's already defined, but I don't expect you to have
interesting networks as of yet.
It may not be easy, but I'd be grateful if you report here on what you
will have accomplished.
7:14 p.m.
On Mon, May 12, 2014 at 5:39 PM, Dan Kenigsberg <danken(a)redhat.com> wrote:
A big limitation of the macvtap approach is that it would let you
connect only a single VM to your WiFi. Is that fine by you?
I wasnt aware of that limitation. No, a single VM limitation would not
be sufficient. I was assuming you could simply do something like this
:
ip link add link wlp2s0 name macvtap0 type macvtap
ip link add link wlp2s0 name macvtap1 type macvtap
ip link add link wlp2s0 name macvtap2 type macvtap
And then assign individual 'interfaces' macvtap0, macvtap1 and
macvtap2 to different VM's. Apparently it doesnt work that way.
Yes, defining a libvirt network requires using
virsh net-define <xmlfile>
(you may need to pass the not-so-secret vdsm@ovirt/shibboleth password
to tinker with libvirt, which is better done on non-production setup)
virsh net-dumpxml <net-name>
could show you what's already defined, but I don't expect you to have
interesting networks as of yet.
Thanks, ill start fooling around with virsh net-define and virsh
net-dumpxml then.
It may not be easy, but I'd be grateful if you report here on what you
will have accomplished.
No problem. Although after having read your last message, I think I
may be better off using (and start with looking at) your NAT-based
network / vdsm-hook-extnet approach.
Regards,
John Smith.
8:44 p.m.
On Mon, May 12, 2014 at 06:14:40PM +0200, John Smith wrote:
On Mon, May 12, 2014 at 5:39 PM, Dan Kenigsberg
<danken(a)redhat.com> wrote:
>
> A big limitation of the macvtap approach is that it would let you
> connect only a single VM to your WiFi. Is that fine by you?
>
I wasnt aware of that limitation. No, a single VM limitation would not
be sufficient. I was assuming you could simply do something like this
:
ip link add link wlp2s0 name macvtap0 type macvtap
ip link add link wlp2s0 name macvtap1 type macvtap
ip link add link wlp2s0 name macvtap2 type macvtap
And then assign individual 'interfaces' macvtap0, macvtap1 and
macvtap2 to different VM's. Apparently it doesnt work that way.
Maybe it does - please try or wait for someone in the know (such as mst) to
explain. The thing is that afaik
http://libvirt.org/formatnetwork.html#examplesDirect creates the macvtap
devices for you, and it creates one device per one virtual function.
>
> Yes, defining a libvirt network requires using
>
> virsh net-define <xmlfile>
>
> (you may need to pass the not-so-secret vdsm@ovirt/shibboleth password
> to tinker with libvirt, which is better done on non-production setup)
>
> virsh net-dumpxml <net-name>
>
> could show you what's already defined, but I don't expect you to have
> interesting networks as of yet.
>
Thanks, ill start fooling around with virsh net-define and virsh
net-dumpxml then.
>
> It may not be easy, but I'd be grateful if you report here on what you
> will have accomplished.
>
No problem. Although after having read your last message, I think I
may be better off using (and start with looking at) your NAT-based
network / vdsm-hook-extnet approach.
NB: Even if it is possible to define a libvirt network with several
pre-created macvtaps, you'd need something like vdsm-hook-extnet to
convince oVirt to use your network instead of a bridge.
Dan.
10:40 p.m.
On Mon, May 12, 2014 at 7:44 PM, Dan Kenigsberg <danken(a)redhat.com> wrote:
or wait for someone in the know (such as mst) to explain.
Guess ill do that, then.
The thing is that afaik
http://libvirt.org/formatnetwork.html#examplesDirect creates the macvtap
devices for you, and it creates one device per one virtual function.
Hrm. here the docs talk about 'interface pools', where presumably, you
can map (combine/bond) multiple physical interfaces to a single
virtual interface, instead of the other way around: mapping a single
physical interface to multiple virtual interfaces.
NB: Even if it is possible to define a libvirt network with several
pre-created macvtaps, you'd need something like vdsm-hook-extnet to
convince oVirt to use your network instead of a bridge.
... because ovirt is hardwired to work with linux network bridges only
? maybe i should just stop fooling around with ovirt altogether, and
just start work on custom tooling to work with kvm and macvtap
directly: all of the restrictions appear to be in the ovirt management
layer and not in the underlying virtualization technologies like kvm
or macvtap ?
Regards,
John Smith.
12:12 p.m.
On Mon, May 12, 2014 at 09:40:20PM +0200, John Smith wrote:
On Mon, May 12, 2014 at 7:44 PM, Dan Kenigsberg
<danken(a)redhat.com> wrote:
>
> or wait for someone in the know (such as mst) to explain.
>
Guess ill do that, then.
>
> The thing is that afaik
> http://libvirt.org/formatnetwork.html#examplesDirect creates the macvtap
> devices for you, and it creates one device per one virtual function.
>
Hrm. here the docs talk about 'interface pools', where presumably, you
can map (combine/bond) multiple physical interfaces to a single
virtual interface, instead of the other way around: mapping a single
physical interface to multiple virtual interfaces.
>
> NB: Even if it is possible to define a libvirt network with several
> pre-created macvtaps, you'd need something like vdsm-hook-extnet to
> convince oVirt to use your network instead of a bridge.
>
... because ovirt is hardwired to work with linux network bridges only
? maybe i should just stop fooling around with ovirt altogether, and
just start work on custom tooling to work with kvm and macvtap
directly: all of the restrictions appear to be in the ovirt management
layer and not in the underlying virtualization technologies like kvm
or macvtap ?
It is unavoidable that any management level in a software stack adds
abstractions and requirements.
If you are planning to run only a couple of VMs on a single laptop,
going to basics and using qemu/libvirt directly, or gnome-boxes, would
make sense.
If you plan to manage a multitude of hosts, then the benefits of oVirt
comes to play.
To your specific point, I am aware of two restrictions. One, of Linux
not supporting bridging wifi. The other is oVirt's reliance on bridges
for VM connectivity. The second restriction is avoidable, but requires
some tinkering. If you decide to try it out, I'd love if you report your
success or challenges on this list.
Dan.
12:22 p.m.
Am 13.05.2014 11:12, schrieb Dan Kenigsberg:
If you are planning to run only a couple of VMs on a single laptop,
going to basics and using qemu/libvirt directly, or gnome-boxes, would
make sense.
If you plan to manage a multitude of hosts, then the benefits of oVirt
comes to play.
In the long run, it would be a huge achievement to utilize ovirt
even for little vm workloads, especially if you want to compete
with vmware.
I know "one size never fits all" but I guess ovirt could very well
be improved for single host management as well.
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
2:45 a.m.
On 05/13/2014 05:22 AM, Sven Kieske wrote:
Am 13.05.2014 11:12, schrieb Dan Kenigsberg:
> If you are planning to run only a couple of VMs on a single laptop,
> going to basics and using qemu/libvirt directly, or gnome-boxes, would
> make sense.
>
> If you plan to manage a multitude of hosts, then the benefits of oVirt
> comes to play.
In the long run, it would be a huge achievement to utilize ovirt
even for little vm workloads, especially if you want to compete
with vmware.
I know "one size never fits all" but I guess ovirt could very well
be improved for single host management as well.
single host management is not the same as roaming laptop with wireless...
all-in-one and hosted engine should provide a decent solution for single
host management - what are the gaps?
9:43 a.m.
On Wed, May 14, 2014 at 1:45 AM, Itamar Heim <iheim(a)redhat.com> wrote:
On 05/13/2014 05:22 AM, Sven Kieske wrote:
>
> Am 13.05.2014 11:12, schrieb Dan Kenigsberg:
>>
>> If you are planning to run only a couple of VMs on a single laptop,
>> going to basics and using qemu/libvirt directly, or gnome-boxes, would
>> make sense.
>>
>> If you plan to manage a multitude of hosts, then the benefits of oVirt
>> comes to play.
>
>
> In the long run, it would be a huge achievement to utilize ovirt
> even for little vm workloads, especially if you want to compete
> with vmware.
>
> I know "one size never fits all" but I guess ovirt could very well
> be improved for single host management as well.
>
single host management is not the same as roaming laptop with wireless...
all-in-one and hosted engine should provide a decent solution for single
host management - what are the gaps?
For what it's worth: my system is not a roaming laptop. it's a fairly
big desktop system that has a wireless interface. so in my case i
think we might still be talking about 'single host management'. The
reason i have wireless adapters in my desktops as well is because i
couldnt easily wire the entire house. Perhaps these days, this is not
such an uncommon configuration as you might think, and wireless is no
longer only common in portable or laptop systems but in desktops as
well.
Anyway, I just wanted to try out this enterprise grade/level
virtualization stack on a single node, just to see how it works and
where the good/bad points are. Other people might want to try this for
similar purposes, kick the tires a bit before a full blown formal
multi host pilot is attempted. The 'All-In-One' installation/setup is
meant to address that; i was hoping it would be a good fit for me as
well.
Regards,
John Smith.
12:45 p.m.
On Wed, May 14, 2014 at 08:43:40AM +0200, John Smith wrote:
On Wed, May 14, 2014 at 1:45 AM, Itamar Heim <iheim(a)redhat.com>
wrote:
> On 05/13/2014 05:22 AM, Sven Kieske wrote:
>>
>> Am 13.05.2014 11:12, schrieb Dan Kenigsberg:
>>>
>>> If you are planning to run only a couple of VMs on a single laptop,
>>> going to basics and using qemu/libvirt directly, or gnome-boxes, would
>>> make sense.
>>>
>>> If you plan to manage a multitude of hosts, then the benefits of oVirt
>>> comes to play.
>>
>>
>> In the long run, it would be a huge achievement to utilize ovirt
>> even for little vm workloads, especially if you want to compete
>> with vmware.
>>
>> I know "one size never fits all" but I guess ovirt could very well
>> be improved for single host management as well.
>>
>
> single host management is not the same as roaming laptop with wireless...
> all-in-one and hosted engine should provide a decent solution for single
> host management - what are the gaps?
>
For what it's worth: my system is not a roaming laptop. it's a fairly
big desktop system that has a wireless interface. so in my case i
think we might still be talking about 'single host management'. The
reason i have wireless adapters in my desktops as well is because i
couldnt easily wire the entire house. Perhaps these days, this is not
such an uncommon configuration as you might think, and wireless is no
longer only common in portable or laptop systems but in desktops as
well.
Anyway, I just wanted to try out this enterprise grade/level
virtualization stack on a single node, just to see how it works and
where the good/bad points are. Other people might want to try this for
similar purposes, kick the tires a bit before a full blown formal
multi host pilot is attempted. The 'All-In-One' installation/setup is
meant to address that; i was hoping it would be a good fit for me as
well.
I still hope that it would, despite the need to tweak and hack it a bit,
and we'd be here to help.
2:01 p.m.
On 05/14/2014 05:45 AM, Dan Kenigsberg wrote:
On Wed, May 14, 2014 at 08:43:40AM +0200, John Smith wrote:
> On Wed, May 14, 2014 at 1:45 AM, Itamar Heim <iheim(a)redhat.com> wrote:
>> On 05/13/2014 05:22 AM, Sven Kieske wrote:
>>>
>>> Am 13.05.2014 11:12, schrieb Dan Kenigsberg:
>>>>
>>>> If you are planning to run only a couple of VMs on a single laptop,
>>>> going to basics and using qemu/libvirt directly, or gnome-boxes, would
>>>> make sense.
>>>>
>>>> If you plan to manage a multitude of hosts, then the benefits of oVirt
>>>> comes to play.
>>>
>>>
>>> In the long run, it would be a huge achievement to utilize ovirt
>>> even for little vm workloads, especially if you want to compete
>>> with vmware.
>>>
>>> I know "one size never fits all" but I guess ovirt could very well
>>> be improved for single host management as well.
>>>
>>
>> single host management is not the same as roaming laptop with wireless...
>> all-in-one and hosted engine should provide a decent solution for single
>> host management - what are the gaps?
>>
>
> For what it's worth: my system is not a roaming laptop. it's a fairly
> big desktop system that has a wireless interface. so in my case i
> think we might still be talking about 'single host management'. The
> reason i have wireless adapters in my desktops as well is because i
> couldnt easily wire the entire house. Perhaps these days, this is not
> such an uncommon configuration as you might think, and wireless is no
> longer only common in portable or laptop systems but in desktops as
> well.
>
> Anyway, I just wanted to try out this enterprise grade/level
> virtualization stack on a single node, just to see how it works and
> where the good/bad points are. Other people might want to try this for
> similar purposes, kick the tires a bit before a full blown formal
> multi host pilot is attempted. The 'All-In-One' installation/setup is
> meant to address that; i was hoping it would be a good fit for me as
> well.
I still hope that it would, despite the need to tweak and hack it a bit,
and we'd be here to help.
to play with it, in an environment that works with wireless, the
ovirt-live (usb boot) would work. but it will evaporate on power down...
3:27 p.m.
On Wed, May 14, 2014 at 1:01 PM, Itamar Heim <iheim(a)redhat.com> wrote:
to play with it, in an environment that works with wireless, the ovirt-live
(usb boot) would work. but it will evaporate on power down...
In what way(s) does the ovirt-live (usb boot) differ from the
All-In-One install I performed ?
Regards,
John Smith.
3:43 p.m.
On 05/15/2014 08:27 AM, John Smith wrote:
On Wed, May 14, 2014 at 1:01 PM, Itamar Heim <iheim(a)redhat.com>
wrote:
>
> to play with it, in an environment that works with wireless, the ovirt-live
> (usb boot) would work. but it will evaporate on power down...
In what way(s) does the ovirt-live (usb boot) differ from the
All-In-One install I performed ?
ovirt-live runs from memory, not installed. designed for
demo/play-around environments, which usually include laptops with
wireless in demo booths, hence supposed to work with wireless.
but that's really only for "playing around" to see how it looks, since
it will evaporate on boot.
7:07 p.m.
On Thu, May 15, 2014 at 2:43 PM, Itamar Heim <iheim(a)redhat.com> wrote:
On 05/15/2014 08:27 AM, John Smith wrote:
>
> On Wed, May 14, 2014 at 1:01 PM, Itamar Heim <iheim(a)redhat.com> wrote:
>>
>>
>> to play with it, in an environment that works with wireless, the
>> ovirt-live
>> (usb boot) would work. but it will evaporate on power down...
>
>
> In what way(s) does the ovirt-live (usb boot) differ from the
> All-In-One install I performed ?
>
ovirt-live runs from memory, not installed. designed for demo/play-around
environments, which usually include laptops with wireless in demo booths,
hence supposed to work with wireless.
but that's really only for "playing around" to see how it looks, since it
will evaporate on boot.
So, what exactly, does ovirt-live do differently, that makes it work
with wireless ? Assuming I can make the same configuration and/or
software changes to make the All-In-One installation work with
wireless, once I know what that is exactly.
Regards,
John Smith
4 a.m.
On 05/15/2014 12:07 PM, John Smith wrote:
On Thu, May 15, 2014 at 2:43 PM, Itamar Heim <iheim(a)redhat.com>
wrote:
> On 05/15/2014 08:27 AM, John Smith wrote:
>>
>> On Wed, May 14, 2014 at 1:01 PM, Itamar Heim <iheim(a)redhat.com> wrote:
>>>
>>>
>>> to play with it, in an environment that works with wireless, the
>>> ovirt-live
>>> (usb boot) would work. but it will evaporate on power down...
>>
>>
>> In what way(s) does the ovirt-live (usb boot) differ from the
>> All-In-One install I performed ?
>>
>
> ovirt-live runs from memory, not installed. designed for demo/play-around
> environments, which usually include laptops with wireless in demo booths,
> hence supposed to work with wireless.
> but that's really only for "playing around" to see how it looks, since
it
> will evaporate on boot.
>
So, what exactly, does ovirt-live do differently, that makes it work
with wireless ? Assuming I can make the same configuration and/or
software changes to make the All-In-One installation work with
wireless, once I know what that is exactly.
hacking it a bit...
this will show you how/where:
git clone git://gerrit.ovirt.org/ovirt-live
grep -r wlan
6:45 p.m.
On Fri, May 16, 2014 at 3:00 AM, Itamar Heim <iheim(a)redhat.com> wrote:
hacking it a bit...
this will show you how/where:
git clone git://gerrit.ovirt.org/ovirt-live
grep -r wlan
Which shows the following results :
- add a 'etc/sysconfig/network-scripts/ifcfg-wlan0' interface script
for the wifi interface (which is 'wlp2s0' in my case and not 'wlan0')
- remove 'wlan*' from the line (which isnt present at all in my config
to begin with) that reads 'hidden_nics = wlan\*,usb\*' in
/etc/vdsm/vdsm.conf
- add 'fake_nics = dummy0' to /etc/vdsm/vdsm.conf
Somehow I doubt that making only these changes to my All-In-One
install on Fedora19 will results in a working wifi ovirt setup.
;)
Anyway, I noticed that ovirt-live is based on RHEL6/CentOS 6. I tried
to install CentOS 6.5 on this system earlier, and failed at the
network/wifi/interface connection/configuration/setup step so I
couldnt get networking working at all with RHEL6/CentOS 6, and if
ovirt-live is based on that I guess the same will happen when booting
ovirt-live. I couldnt figure out what the issue was but i guess it's a
driver and/or kernel issue with CentOS 6.5 .
6:46 p.m.
On Wed, May 14, 2014 at 11:45 AM, Dan Kenigsberg <danken(a)redhat.com> wrote:
I still hope that it would, despite the need to tweak and hack it a bit,
and we'd be here to help.
Guess ill take a look at that NAT-based network / vdsm-hook-extnet
approach you mentioned then.
Regards,
John Smith.
3843
days inactive
3855
days old
19 comments
4 participants
participants (4)
-
Dan Kenigsberg -
Itamar Heim -
John Smith -
Sven Kieske