Hi All,
I am using a Quemu/KVM and my VM gets network x.x.10.180 but I want to have this machine in the same range as the host x.x.7.71 is there any way doing it?
Sorry, but networks are defined by the FIRST number of bits (often 24 of them) of the address. You only show last numbers. The first few bits of what you post may be part of the network, but the rest up to the end is the host address.
Thus your information is of not much use to explain what you have.
Netwrorks are written down as e.g. 10.0.0.0/24, which means that the first 10.0.0 is the network and the remaining 8 bits are available for hosts (minus 0 and 255).
hi I am sorry I thought this is obvious. Lets say:
I am using a Quemu/KVM and my VM gets network 192.168.122.68 but I want to have this machine in the same range as the host 192.168.2.158 is there any way doing it?
but the problem is different. I have changed the network manually on the VM to match the host range 192.168.2.160 and almost ok but the host and VM cant see to each other.
I think you should have added what one (or both) networks are, by either showing the netwmask, or by doing it as I did above.
IMHO there are two possibilities now:
- the netmask is 255.255.255.0, which would make both networks 192.168.122.0/24 and 192.122.2/24;
- or the netmask is 255.255.0.0, which would make only one network 192.168.0.0/16.
And even many more possibilities of subnetting.
But I assume the first one above is what you mean because else both systems would already belong to the same network.
You need to setup the networking of KVM/Qemu differently. You now have a NAT bridge ( I can see that from the defaults ), where you want the VM to use the physical network. I’ve never used that, so have no experience in setting such up, but I know f.e. virt-manager shows these options.
Just putting my 2 cents based on my experience.
If I may ask, what do you need to achieve by putting VM guest and host in the same subnet?
If you just want bidirectional host <-> guest(s) -in case you have more VM guests in the host- communication, the (default) NAT virtual network is just enough.
Just one detail with Windows VMs: guest → host communication works, but firewall service blocks host → guest communication out of the box. In my case I had to disable the service and reboot Windows VM; I’m not sure if it’s possible to somewhat add rules/exceptions to Windows firewall…
With NAT network you can also ping devices within host’s physical LAN from VM guest, but they cannot ping the VM; this is how NAT works. As a note, you may have noticed that virtual network wizard doesn’t allow to set subnet the same as host’s subnet, giving error instead.
If you also need LAN devices to see the VM guest(s) inside your host, most direct way -in summary; I haven’t done it myself yet- is creating a network bridge in your host and use it for both your VM guests (the bridge will be visible when configuring network in the create VM wizard), and also your ethernet device itself.
This network bridge method effectively puts both VM guest(s) and physical LAN in the same subnet.
To create a bridge with Network Manager one can either use nmcli command line, or nm-connection-editor for GUI (installing NetworkManager-connection-editor package). I think there are several tutorials around internet regarding both.
One can also create bridges using Yast; in fact Yast offers to create one when first installing the virtualization stuff via Yast’s virtualization module. But Yast’s bridges seem to be only usable for Wicked, not Network Manager.
It’s been said here in the forums that wireless network devices cannot be added to a bridge, however Arch Linux and Debian wikis say it’s possible, though more convoluted. Probably just less practical…
Finally, aside NAT network, there’s also the “routed” option in libvirt’s virtual networks. But as far as I read, it’s a more advanced, commonly less used configuration. Kind of aimed to making “secured network zones”, and involves adding correct routes to individual LAN devices and/or LAN router to achieve communication with the VMs.
I’ll agree with Knurpht.
Here, my VMs are on the same network as the host. But that’s because I set them up to use a bridge instead of using NAT. So they get their IP from the general network router.
I don’t actually need this, and the next time that I install virtualization tools, I’ll probably set it to use NAT. But, when using NAT, it will need to use a different subnet for the VMs to avoid a conflict.
If you installed KVM using the YaST virtualization module,
You would already have a bridge called br0, you would then simply re-configure your Guest’s Networking properties (using vm manager most likely). That puts your Guest on the same physical network as your HostOS and every other machine in your LAN. If your LAN has a DHCP server, you can configure your Guest to be a DHCP client for easy network configuration, otherwise you’d have to configure a static address, default gateway and DNS manually.
If you didn’t install KVM using the YaST module, you can create a “bridging” bridge device using vm manager (create a virtual network), YaST or command line using the “brctl” utility, or even nmcli or Network Manager (these I don’t necessarily recommend). IIRC all these methods should set up a “bridging” bridge device if you simply accept all defaults (I haven’t checked all in a very long time, though).
Otherwise, if you haven’t done anything special (Assuming as a beginner you didn’t go wildly off track on what you’re allowed to do by default), you might be able to simply run the YaST virtualization module even after manual installation of KVM and perhaps libvirt to be properly installed with no missing parts and with a standardized configuration.
Although not applicable to initial installation, I recommend the SLES 11 SP4 virtualization documentation for configuration topics like this Forum post/thread, although ti’s getting very old the info is still the most accurate published by SUSE/openSUSE
https://www.suse.com/documentation/opensuse114/
TSU
Additionally,
My previous post only addresses how to set up your Guest so that it’s on the same Network as your HostOS and LAN.
For the very special situation communicating between Guest and HostOS, although you will find that although you should be able to communicate by IP address, typically you will still not be able to communicate by name… And this is because ordinarily there is no common name authority shared between Guest and HostOS (this is true of all virtualization technologies, not just KVM). The name servies provided in a NAT bridge device environment will be unaware of the HostOS names although it will know the names of each Guest using the same bridge device.
The simple solution of you want name resolution between Guest and HostOS is to recognize the issue, and address it… Probably the most common and simplest is to point the Guest and Host to an “external” DNS, eg if one exists on your LAN, but would still have to look at how DNS entries are populated. Or, the alternative is to create appropriate host file entries on each machine.
TSU
…or consider using Avahi local hostname resolution perhaps. (That suits my needs just fine.)
Where?
As far as I can see there are only 3 options: NAT (default), routed, isolated.
None of them is a “bridge”
When I use Yast Virtualization to install KVM, it offered to setup a bridge. So I went with that.
See if this graphical guide helps
Thanks, but AFAICS mr tsu implied creating the network bridge device directly from within libvirt’s virtual networks, which is what I meant.
Been awhile since I’ve done this in vm manager,
Nowadays I save myself the trouble and just create it using the YaST virtualization “Install Hypervisor and Tools” module.
Found the following, complete with screenshots,
Creating a bridge device involves creating a new network interface, this makes sense in a way because you’re not actually creating a new virtual network, only the interface that forwards to the physical network.
Any viewer should consider this only for informational purposes,
Although a bridging bridge interface can be created this way, it’s far better to just install using the YaST virtualization module and allow br0 to be created for you automatically, there is less room for error.
TSU