<div dir="ltr">On Sat, Aug 2, 2014 at 10:02 AM, unsolicited <span dir="ltr"><<a href="mailto:unsolicited@swiz.ca" target="_blank">unsolicited@swiz.ca</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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 ...<br>
</blockquote><div><br></div><div>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).<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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?<br>
</blockquote><div><br></div><div>Initally, I was using a somewhat risky setup. <br><br>$ sudo virt-install --name t1 \<br> --ram 512 \<br> --disk path=./t1.img,format=qcow2,bus=virtio \ <br> --autostart \ <br> --graphics vnc,listen=0.0.0.0 \<br>
--network bridge=br0,mac=52:54:00:00:00:11 \<br> --boot hd \<br> --disk path=./media/init/init.iso,bus=virtio<br> <br></div><div>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).<br>
<br></div><div>The reason I had to use this is that I was using KRDC from the laptop<br><br>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.<br>
<br>$ virt-viewer -c qemu+ssh://your-host/system t1<br><br></div><div>This means your consoles for the VMs are protected via ssh, and only those who have keys can view it.<br></div><div><br></div><div>That is sufficient security in my book ...<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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.<br>
</blockquote><div><br></div><div>Can't comment on any of that, since I did not try it.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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.<br>
</blockquote><div><br></div><div>That too. I just assign a unique MAC address to each VM, and assign it an IP address in the router.<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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!</blockquote>
<div><br></div><div>No, all the setup I talked about is not meant to run any real load, nor stay up all the time. Just for testing. <br></div></div>-- <br>Khalid M. Baheyeldin<br><a href="http://2bits.com" target="_blank">2bits.com</a>, Inc.<br>
Fast Reliable Drupal<br>Drupal optimization, development, customization and consulting.<br>Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra<br>Simplicity is the ultimate sophistication. -- Leonardo da Vinci<br>
For every complex problem, there is an answer that is clear, simple, and wrong." -- H.L. Mencken<br>
</div></div>