On Wed, 14 Dec 2011 22:41:42 +0100
Florian Heigl <florian.heigl_at_gmail.com> wrote:
> Hi Natanael,
> 2011/12/8 Natanael Copa <ncopa_at_alpinelinux.org>:
> > Hi,
> > I have been using qemu for some time for testing and network
> > development.
> > I think raw qemu is a bit cumbersome since i need to keep track of
> > the mac address of all the guests. When I create a guest i create a
> > start.sh script where i stuff in the mac address. (I sometimes need
> > multiple NICs in guests and will need multiple guest vlans etc.
> I can offer two things:
> Help you with dealing with the XML files needed for use with Libvirt
> and making the networks autostart.
I use /etc/init.d/vde.tap$N atm to start the virtual switches. and add
the tap devices to bridges together with the ether interfaces.
this works farily well now, even if it was not really trivial to set up.
This is done completely without any xml files and I still use shell
scripts with mac adresses for qemu.
> Work together to make the Xen port 100% usable and give hints on how
> to use it for a desktop-py scenario
The stopper for me was that xorg didnst start in my dom0 with Sandy
Bridge. IT did start on the old box with ATI card. (Maybe i shouldnt
start xorg in dom0 in first place?)
switching from xorg to tty didnt work either. (ctrl-alt-1 etc)
> I would be happy about the second since it would be good to work on
> that. Not saying that it wouldn't help me a lot, too ;)
> Also I'm afraid there will be two half-working virtualization
> solutions instead of one well-working one, since I except Virtualbox
> to be a lot of work to package / make work.
> VirtualBox can also be run under libvirt control, or without it. This
> year i've probably launched, tested and deleted 600 or so libvirt VMs,
> and had no problems with it.
> But there is a fine line to it. My workmates had tried to build the
> autobuild cluster for our check_mk build using it and virtualbox kept
> going topside down, with a wide choice of different errors.
> But, to be clear on that, on my work laptop and on the desktop at
> home, virtualbox is the #1 choice. I'll also use KVM on the desktop
> for OpenNebula testing, but that means it's stricly as a "server" like
> scenario. Mostly I blame that on Libvirt idiocy.
> One last thing one should mention: VirtualBox is the least user
> friendly of the pack once you're using the CLI for automating install
> tests, etc.
> Cool thing is that VirtualBox has great PXE support, emulates Intel
> NICs instead of Realcrap[tm].
> I wouldn't object using as a desktop thing Xen instead if I had a
> distro that gave me a working Xen install. Although, honestly, stuff
> like mounting and unmounting of ISOs is about 5000% more complicated
> there than anywhere else ;)
> So, err, this is a rather undecided reply.
> Poke at Virtualbox, and if you think you can port it in 1-2 days, then
> go with virtualbox.
I have started with this but it seems like it still needs some work :-/
> Otherwise, or once you want automated installs, memory compression,
> dumping live VM memory, scripting, etc. and a general notation of
> "bleeding edge", switch to Xen.
I found xen seems to be pretty complicated for desktop use. For now I
think the simplest solution for me is continue use qemu. Maybe get it
working with libvirtd. Ping me on IRC if you have time to help me set
I got spice working with qemu too.
Thanks a lot for your insightsful comments!
Received on Thu Dec 15 2011 - 11:33:55 UTC