[kwlug-disc] Networking on libvirt vs. VirtualBox

[Khalid Baheyeldin]

On Sat, Aug 2, 2014 at 10:02 AM, unsolicited <unsolicited at swiz.ca> wrote:

> 1. With vbox there is no entry into the BIOS, unlike vmware. That's not
> necessarily bad, but it also means there's no BIOS level IBM KVM-like
> attach screen to virtual machine facility. So if a vbox is run headless,
> and you fail to set up some form of remote access, and it doesn't appear to
> be running correctly ...
>

If you managed to save an image that enables incoming ssh connections, and
got it to boot successfully, you will almost never need the console,
because there are no hardware parts that can go bad. So, for me, console is
not needed beyond the initial install (via VNC or RDP or whatever).


> 2. How to make this safe in one's own network? In a provided cloud,
> presumably they're guaranteeing absolute machine isolation - it's their
> back end networking. At 'home' everything must inherently participate in
> the local network, else you could not maintain it, yet how to otherwise
> isolate it for the world, to run LAMP plus favourite serving applications?
>

Initally, I was using a somewhat risky setup.

$ sudo virt-install --name t1 \
   --ram 512 \
   --disk path=./t1.img,format=qcow2,bus=virtio \
   --autostart \
   --graphics vnc,listen=0.0.0.0 \
   --network bridge=br0,mac=52:54:00:00:00:11 \
   --boot hd \
   --disk path=./media/init/init.iso,bus=virtio

See that 0.0.0.0? This means VNC will listen on the all interfaces, and
hence anyone (on the LAN) will be able to connect to the console of the VM
(but will still need the password to get it).

The reason I had to use this is that I was using KRDC from the laptop

Then I discovered virt-viewer, and that it can tunnel over ssh. So the
listen can be changed to 127.0.0.1, or omitted altogether, then from the
laptop use virt-viewer directly to the instance you are interested in
without knowing port numbers and such.

$ virt-viewer -c qemu+ssh://your-host/system t1

This means your consoles for the VMs are protected via ssh, and only those
who have keys can view it.

That is sufficient security in my book ...

- bridged, and router subnet forwarding, is intuitive, let alone internal
> machine magic to understand public/private IP presentment, but otherwise???
> Virtual VLAN? While still being able to access locally in order to
> maintain. The networking should be able to prevent any security hole
> discovery / attack, but the conceptual networking setup specifics elude me
> at the moment. Remotely things would be on a separate DMZ network, with
> machines not able to talk to each other (separate VLANs), but that's more
> hardware, let alone not virtual, than I might want on my own desktop.
>

Can't comment on any of that, since I did not try it.


> - only thing I have thought of is each vm on it's own virtual net,
> pointing one's router for a supernet of them to the host, and turn routing
> on on the host. Not sure what that's buying, as the local net must still be
> able to get to them to maintain. All in the effort of properly isolating
> vmachines.
>

That too. I just assign a unique MAC address to each VM, and assign it an
IP address in the router.

Hint, you can assign your own unique MAC addresses in the range
52:54:00:xx:xx:xx range which is assigned for KVM as a vendor.


> In Khalid's case, he could even have a service offering of a redundant,
> albeit slow, site in case of provider down time, such as provider under
> DDOS attack. A UPS, beefy tower, good to go!


No, all the setup I talked about is not meant to run any real load, nor
stay up all the time. Just for testing.
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
Fast Reliable Drupal
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
For every complex problem, there is an answer that is clear, simple, and
wrong." -- H.L. Mencken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20140802/3514f960/attachment.htm>