PDA

View Full Version : I see vortexbox in a vm as a good solution



pski
2010-08-19, 16:13
Could we start a thread/area about vm's on various platforms?

JJZolx
2010-08-19, 16:27
Why? If you have a dedicated machine on which to run Squeezebox Server then the VM is just added overhead and administrative complexity.

And Vortexbox has unnecessary components that most people don't need on a dedicated server.

epoch1970
2010-08-20, 00:57
Why? If you have a dedicated machine on which to run Squeezebox Server then the VM is just added overhead and administrative complexity.
I beg to differ. You just can't ignore the fact that performing a rollback on a VM after an unsuccessful upgrade is so simple, compared to downgrading a machine. In the context where most people want their music server to "simply work", and the promise of a distro such as Vortexbox is to install all the elements of a music server just popping the install CD, then running and maintaining Vortexbox in a VM makes sense to me. Not all people will dedicate a server, but some could (read: should) dedicate a VM.
I can agree on the fact that some elements like power management may be out of place in a VM.

FreeNAS on a VM seems quite a candidate to me as well. Although my recent experience with a linux host running kvm tells me availability of the virtio device drivers (for disks, network cards) on the guest is a must have. Virtio drivers are available on linux and windows, not (yet?) on Bsd.

Also, I still hope to see SBS updates rolled as complete system images. It simplifies so much testing, I can't believe the Slim devices people are not using this method internally.

My personal policy wrt VMs is generally: 1. try to install from plain ISOs, 2. use a system drive format that can be mounted/modified easily without the VM manager (e.g. raw image file), 3. rely on file storage on the host for data rather than put it in the system drive image (e.g. do internal NFS mounts), 4. setup networks outside the VM manager (e.g. my own bridges, not the default NAT network)
I didn't come with this recipe on the first try, and there certainly is a learning curve, either for the host or for the guests. So I guess exchanging on the subject can be of interest.

I'd also like that we could avoid confusing "VM" with WMware, notwithstanding its merits, esp. for Windows users.

elstensoftware
2010-08-20, 07:36
Not sure if it is of any help, but I wrote a blog post about installing vortexbox in vmware server (http://www.blisshq.com/music-library-management-blog/2010/03/23/automatic-digital-music-workflow-with-vortexbox-part-one-installation/).

I tried VirtualBox too, but had less success, I found that ripping was not supported (http://vortexbox.org/forum/general/vortexbox-in-virtualbox-ripping-not-supported/). I've also got some experience with Hyper-V and Xen and I have to say, when it comes down to flexibility, management and performance, VMware are still ahead of the competition.

iPhone
2010-08-20, 08:03
I beg to differ. You just can't ignore the fact that performing a rollback on a VM after an unsuccessful upgrade is so simple, compared to downgrading a machine. In the context where most people want their music server to "simply work", and the promise of a distro such as Vortexbox is to install all the elements of a music server just popping the install CD, then running and maintaining Vortexbox in a VM makes sense to me. Not all people will dedicate a server, but some could (read: should) dedicate a VM.
I can agree on the fact that some elements like power management may be out of place in a VM.

FreeNAS on a VM seems quite a candidate to me as well. Although my recent experience with a linux host running kvm tells me availability of the virtio device drivers (for disks, network cards) on the guest is a must have. Virtio drivers are available on linux and windows, not (yet?) on Bsd.

Also, I still hope to see SBS updates rolled as complete system images. It simplifies so much testing, I can't believe the Slim devices people are not using this method internally.

My personal policy wrt VMs is generally: 1. try to install from plain ISOs, 2. use a system drive format that can be mounted/modified easily without the VM manager (e.g. raw image file), 3. rely on file storage on the host for data rather than put it in the system drive image (e.g. do internal NFS mounts), 4. setup networks outside the VM manager (e.g. my own bridges, not the default NAT network)
I didn't come with this recipe on the first try, and there certainly is a learning curve, either for the host or for the guests. So I guess exchanging on the subject can be of interest.

I'd also like that we could avoid confusing "VM" with WMware, notwithstanding its merits, esp. for Windows users.

Well said. I would concede the point about SBS updates as to Windows or Mac boxes, but I have yet to have a Yum Update go wrong on a Linux box using Vortexbox. But never the less your point is well taken.

pski
2010-08-20, 20:42
Not sure if it is of any help, but I wrote a blog post about installing vortexbox in vmware server (http://www.blisshq.com/music-library-management-blog/2010/03/23/automatic-digital-music-workflow-with-vortexbox-part-one-installation/).

I tried VirtualBox too, but had less success, I found that ripping was not supported (http://vortexbox.org/forum/general/vortexbox-in-virtualbox-ripping-not-supported/). I've also got some experience with Hyper-V and Xen and I have to say, when it comes down to flexibility, management and performance, VMware are still ahead of the competition.

Hence my thought about a specific place to post. I would point out also that simple things like RDP can restrict access to hardware (like CD/DVD drives) is a common issue with virtual machines as well.

P

ralphy
2010-08-22, 06:15
4. setup networks outside the VM manager (e.g. my own bridges, not the default NAT network)

I'm curious about this point.

Could you expand on this?

What are you using for the bridge and how do you get the VM and host to talk to each other using it?

Thanks.

epoch1970
2010-08-22, 09:37
So I am running linux (debian mostly), and kvm these days. Before that I was using linux and Virtualbox.
On the linux host I use a package called something like bridge-utils. The command that does it all is brctl.

Let's say we have a debian host with a working plain network configuration:
auto eth0
iface eth0 inet static
address 172.31.0.10
netmask 255.255.0.0
network 172.31.0.0
broadcast 172.31.255.255
gateway 172.31.0.1

Then you can install bridge-utils and change the configuration to this:
auto br0
iface br0 inet static
address 172.31.0.10
netmask 255.255.0.0
network 172.31.0.0
broadcast 172.31.255.255
gateway 172.31.0.1
bridge_ports eth0
bridge_stp on
bridge_maxwait 0

A bridge is like a virtual switch, it resembles the "managed" kind of switches which get an IP on the network. Here, a virtual switch is added on the 172.31.0.0 network, which goes through interface eth0. The "bridge ports eth0" stanza you see here is the equivalent of running the brctl command: 'brctl addif br0 eth0' and plugs the host NIC into the virtual switch.
- All virtual machines with interfaces plugged into the switch will be able to use the eth0 route to reach the physical network (provided they know how to use the 172.31.0.0 network, of course.)
- The host computer is still reachable at address 172.31.0.10

Under VBox or kvm or whatever else I guess, if you create a VM with an interface plugged into the "br0 native host device", then both the host and the guest can be on the same network. DHCP requests work and all.

Create a VM with SBS, give it an ethernet card and you'll get your players to talk to your virtual SBS server as easily as if SBS was running on the physical host.
Note that the MAC address used by the SBS server will be a MAC address generated by the VM manager when creating the virtual machine: you need to reconnect your squeezeboxen properly to this server, the first time.

I've had this work for a few years in Virtualbox (linux and mac hosts), easily if not extremely reliably. This summer I upgraded my main server and switched to using kvm, which is libre and offers much more performance and reliability. Ease of use is a bit on the downside. I can't speak of other options.

Being fast and reliable, KVM opens to much more convoluted configurations.
The one I use is to have multiple networks of physical and virtual machines, routed/filtered by a virtual machine. Only some portions of the server host are accessible to some machines/networks, according to the firewall configuration, yet it runs everything.
A virtualized network is extremely flexible, and a router/firewall VM can be fast, because usually it lives in the belly of a whale, compared to common routers.

Using a recent linux (2.6.32) on a host that has VT cpu extensions (a PowerEdge circa 2006), I started running a Vyatta router as a kvm virtual machine with great success. Vyatta is linux-based and uses the Virtio drivers. I currently route between 5 different networks, balkanization looms :)
I can go further on this virtual router scheme, but between bridging, bonding, VLANs, routing, the subject is a bit numbing. Let me know.

One last word. I replaced the fast SAS 10k rpm system drive in my server with an Intel SATA SSD. It did absolutely nothing to the feel of the server from a workstation, as the network is the bottleneck. But the SSD transfigured the responsiveness of my virtual machines beyond all expectations.

pski
2010-08-23, 15:22
Why? If you have a dedicated machine on which to run Squeezebox Server then the VM is just added overhead and administrative complexity.

And Vortexbox has unnecessary components that most people don't need on a dedicated server.

I would say: Because the VortexBox VM is vastly faster than running SBS without virtualization on the same box.

If you want to avoid all complexity, you probably have a higher-priced music serving alternative. (Pray it's not Bose!)

Please detail the unnecessary components.

P

pski
2010-08-23, 15:27
So I am running linux (debian mostly), and kvm these days. Before that I was using linux and Virtualbox.
On the linux host I use a package called something like bridge-utils. The command that does it all is brctl.

Let's say we have a debian host with a working plain network configuration:
auto eth0
iface eth0 inet static
address 172.31.0.10
netmask 255.255.0.0
network 172.31.0.0
broadcast 172.31.255.255
gateway 172.31.0.1

Then you can install bridge-utils and change the configuration to this:
auto br0
iface br0 inet static
address 172.31.0.10
netmask 255.255.0.0
network 172.31.0.0
broadcast 172.31.255.255
gateway 172.31.0.1
bridge_ports eth0
bridge_stp on
bridge_maxwait 0

A bridge is like a virtual switch, it resembles the "managed" kind of switches which get an IP on the network. Here, a virtual switch is added on the 172.31.0.0 network, which goes through interface eth0. The "bridge ports eth0" stanza you see here is the equivalent of running the brctl command: 'brctl addif br0 eth0' and plugs the host NIC into the virtual switch.
- All virtual machines with interfaces plugged into the switch will be able to use the eth0 route to reach the physical network (provided they know how to use the 172.31.0.0 network, of course.)
- The host computer is still reachable at address 172.31.0.10

Under VBox or kvm or whatever else I guess, if you create a VM with an interface plugged into the "br0 native host device", then both the host and the guest can be on the same network. DHCP requests work and all.

Create a VM with SBS, give it an ethernet card and you'll get your players to talk to your virtual SBS server as easily as if SBS was running on the physical host.
Note that the MAC address used by the SBS server will be a MAC address generated by the VM manager when creating the virtual machine: you need to reconnect your squeezeboxen properly to this server, the first time.

I've had this work for a few years in Virtualbox (linux and mac hosts), easily if not extremely reliably. This summer I upgraded my main server and switched to using kvm, which is libre and offers much more performance and reliability. Ease of use is a bit on the downside. I can't speak of other options.

Being fast and reliable, KVM opens to much more convoluted configurations.
The one I use is to have multiple networks of physical and virtual machines, routed/filtered by a virtual machine. Only some portions of the server host are accessible to some machines/networks, according to the firewall configuration, yet it runs everything.
A virtualized network is extremely flexible, and a router/firewall VM can be fast, because usually it lives in the belly of a whale, compared to common routers.

Using a recent linux (2.6.32) on a host that has VT cpu extensions (a PowerEdge circa 2006), I started running a Vyatta router as a kvm virtual machine with great success. Vyatta is linux-based and uses the Virtio drivers. I currently route between 5 different networks, balkanization looms :)
I can go further on this virtual router scheme, but between bridging, bonding, VLANs, routing, the subject is a bit numbing. Let me know.

One last word. I replaced the fast SAS 10k rpm system drive in my server with an Intel SATA SSD. It did absolutely nothing to the feel of the server from a workstation, as the network is the bottleneck. But the SSD transfigured the responsiveness of my virtual machines beyond all expectations.

I'll need a bit to digest all this good info. It echoes my the pending dominance of kvm I've seen online.

Thanks and I will let you know.

p'ski

JJZolx
2010-08-23, 15:56
I would say: Because the VortexBox VM is vastly faster than running SBS without virtualization on the same box.

It sounds like you're talking about a VM running on system that's also running Windows. If so, you should make that clear. Of course there's no reason to have Windows at all on a dedicated server if you're going to run SbS under *nix. So you must also be talking about running on a Windows desktop that's being used for other purposes.


If you want to avoid all complexity, you probably have a higher-priced music serving alternative.
Most people want to avoid complexity. Installing Squeezebox Server in and of itself is pretty simple.


Please detail the unnecessary components.
CD ripping ability.

NAS emulation.

If you're looking for those things, great, Vortexbox is for you.

But if you're satisfied ripping on a separate PC, or (if, as you allude to) this VM is running on your Windows desktop machine, then you're likely already doing all of your ripping and tagging on that machine. The NAS functionality may be helpful, but it's mostly unnecessary. For an SbS server you're likely only going to need one or two network shares and these can easily be set up without an NAS interface.

dsdreamer
2010-08-24, 20:03
Inspired by this thread I thought I'd give Vortexbox a spin as a guest OS under Ubuntu 10.04, using VmWare's free VMplayer.

This was way easier than trying out the distro on bare metal, which I have done once before. I was highly impressed by how complete and functional Vortexbox is these days. Yummy, in fact :-)

Since my host is a laptop, I don't have a reason to want keep a Virtual Vortexbox running on such a machine, but I did use it to rip a new CD into my collection which it did efficiently and correctly.

Overall, if I were to switch to Vortexbox in a dedicated machine as a storage appliance, I think I'd still install it on bare metal, but as a test environment VMware/Virtualbox has considerable merit. Furthermore, I have enjoyed getting reacquainted with Vortexbox, which I may not have bothered to do had it entailed dedicating a machine to it just for testing purposes.

Best regards,

Charles.