Simple vimage question

[rogerh]

I have a 9.10 system with one 9.3 jail. The jail runs MiniDLNA. It uses storage on the main FreeNAS pool. FreeNAS has two NICs on different subnets. The jails have been allocated some contiguous addresses on one of these subnets. The only active jail has been given the first of these addresses. When I set up this jail I ticked the "vimage" box, because it appeared to be the default, and because I very vaguely thought it was part of bridging. I have since learnt that in my setup vimage may not be necessary and is capable of causing problems.


My question is whether, at this stage, I can simply un-tick vimage and restart the jail without too much risk of problems?

Many thanks for any comments.

 

[SweetAndLow]

You want vimage checked unless you have some very strange reason for your jail to use the same networking stack as your host. If you knew why you didn't need it checked you would need to ask the question so just leave it as is.

 

[rogerh]

You want vimage checked unless you have some very strange reason for your jail to use the same networking stack as your host. If you knew why you didn't need it checked you would need to ask the question so just leave it as is.

Should I mind it using the host networking stack? As long as it gets the packets for its IP address?

 

[SweetAndLow]

If a service in the jail uses the same port as something on the host you will have problems. Do you have a reason to not use vimage? I can't think of any reason you would want to not use it.

 

[rogerh]

If a service in the jail uses the same port as something on the host you will have problems. Do you have a reason to not use vimage? I can't think of any reason you would want to not use it.

Many services can exclusively bind to a given IP address, but I do see the danger. I do seem to get the right sshd for the IP I use. I have no current use case for anything except MiniDLNA, plus whatever routine services are started, in my jails.

My only concern about vimage is @jkh 's remarks in the 1o Alpha2 thread that it is unstable and potentially destructive.

My main concern in this thread is whether a jail originally set up with vimage can safely have it turned off. So far nothing bad has happened, but I haven't got round to checking if MiniDLNA still works.

 

[SweetAndLow]

Nothing bad will happen from checking and unchecked. Also nothing bad will happen from having it on, that is why it's the default.

 

[rogerh]

Nothing bad will happen from checking and unchecked. Also nothing bad will happen from having it on, that is why it's the default.

Thanks!

 

[jkh]

Many services can exclusively bind to a given IP address, but I do see the danger. I do seem to get the right sshd for the IP I use. I have no current use case for anything except MiniDLNA, plus whatever routine services are started, in my jails.

And if you turn off VIMAGE, you will no longer be able to use ssh on port 22 in that jail because, as others have pointed out, you will suffer a port collision.

Here's the basic situation:

1. If you can put every service in every jail on its own unique port and have no collision between those ports and the ports the host wants to use for its own services (like ssh or file sharing or ... whatever ...) then you can elect not to use VIMAGE and you'll be Just Fine.
2. If you're currently using VIMAGE and experiencing no instability issues, then don't worry about it - you're probably not tickling any of the rough edges I talked about in that ALPHA2 thread.

 

[rogerh]

And if you turn off VIMAGE, you will no longer be able to use ssh on port 22 in that jail because, as others have pointed out, you will suffer a port collision.

Here's the basic situation:

1. If you can put every service in every jail on its own unique port and have no collision between those ports and the ports the host wants to use for its own services (like ssh or file sharing or ... whatever ...) then you can elect not to use VIMAGE and you'll be Just Fine.
2. If you're currently using VIMAGE and experiencing no instability issues, then don't worry about it - you're probably not tickling any of the rough edges I talked about in that ALPHA2 thread.

Thanks.

Edit: though as a matter of practical fact if I ssh to the jail's IP I *can* login to the jail by ssh on port 22 (and can still ssh to the FreeNAS server on port 22 at its address). But I shall follow the advice not to rely on this interesting fact.

 

[jgreco]

Thanks.

Edit: though as a matter of practical fact if I ssh to the jail's IP I *can* login to the jail by ssh on port 22 (and can still ssh to the FreeNAS server on port 22 at its address). But I shall follow the advice not to rely on this interesting fact.

Yeah, there's some misinformation going on in this thread, including from people who I would have expected to know better.

By default, FreeNAS binds sshd to "*:22", which is a generic catchall.

If a userland process comes along and binds to a more specific address, such as "1.2.3.4:22", this will succeed. In the case of a jail, what ends up being processed by the kernel looks very much like a userland request to bind to a specific IP *and* port, so typically this will succeed as long as the host platform hasn't also bound to that *specific* address and has instead just bound to the wildcard.

You could also configure FreeNAS to bind sshd to a specific address for management, which is probably a good idea in any case.

 

[rogerh]

Yes, as far as I know you never need to login directly to a jail from the network, you can do most things (?all) via FreeNAS. This thread is more based on idle curiosity about vimage on my part. A positive advantage of vimage is that the GUI reporting includes a separate entry for network traffic from the jail. I am curious whether you get separate entries for each jail, but I don't think I will try to alter my 9.3 jails in 9.10, in case something bad happens. I'm inclined to think with my very simple setup that it will be best to abandon jails altogether when 10 comes out. But I am very grateful for the reassurances about vimage in the meantime.