As Joeqwerty already noted, you're approaching this with an inadequate fundamental understanding, combined with vaguely-defined goals. You are setting yourself up for failure, downtime, and security holes. Rather than just answering your questions as asked I'm going to indulge in a little "vLAN 101" tutorial which might be a bit more useful for you.
You seem to have a few fundamental misconceptions about vLAN segmentation and how it fits into network architecture, so let's roll ALLLLLLL the way back to the beginning for a minute:
From a network architecture level you can take the very simplistic view that a vLAN is nothing more than a separate switch, not connected to any other switch (vLAN).
If you look at vLANs in this way it becomes relatively clear how to use them: When you don't want machines in Group A to be able to talk to machines in Group B you put them in separate vLANs, and force them to traverse a router (ideally one with firewall functionality) to talk to each other.
Under nearly all circumstances it's better (and easier) to do this by also putting the machines in different IP networks (subnets) -- Machines within a vLAN are in the same subnet, and can chat amongst themselves as much as they want, but if they want to talk to someone outside their vLAN it's also going to be outside their subnet, so they get handed off to their default gateway, which can handle the security concern of who can talk to whom under what circumstances.
So vLAN architecture in 11 easy steps:
Figure out which machines form logical groups. These are your vLANs
In a very simple environment this could be Web Servers and Database Servers.
In more complex environments you may have lots of groups, and you may combine multiple groups in a single vLAN -- This is an architecture decision you have to make.
Figure out an addressing scheme that suits your vLANs.
If you're supremely lucky every vLAN will fit into a /24 and you'll be able to build a topology based around that. If you aren't that lucky figure out which vLANs need bigger (or smaller) blocks.
Draw what you have done so far on paper.
Figure out which vLANs need to talk to each other.
What ports/services should be open between vLANs/Networks?
What other conditions need to exist for your environment to function?
Draw what you came up with on paper. Make sure it's sane, then convert it into firewall/router policy.
Draft a firewall/router configuration. Ideally play with it in a test environment.
Draw your switch on paper and map which ports will go to which vLANs.
It's helpful to physically group connections so that they're in the same logical vLAN,
but this isn't strictly necessary.
Turn your switch drawing into a switch configuration. Ideally play with it in a test environment.
Clean up your drawings on paper. The logical drawing should look somewhat like this:
(The image has been shrunk to obscure stuff you don't need to read)
Get someone else to look at your design.
You can ask on Server Fault, but it's better if someone familiar with your environment looks at it as they're more likely to catch potential breakage.
Take a weekend and turn your logical design into a physical reality.
(It should go without saying that you should have a rollback plan in case things go horribly wrong, but I'm saying it anyway.)
(If you are VERY good you might be able to skip some of the "Draw it on paper" steps above, but I don't recommend skipping that your first time.)
Re: the two specific questions you asked:
1)How can I segment this network with minimum down time on the devices already on the network?
You can't. Breaking your network into vLANs will require an outage window - you will have to reconfigure your switch, move machines into different logical networks, configure routing, probably move some cables around, etc. etc. etc.
Plan for an outage starting at 5PM Friday and extending over a weekend, ESPECIALLY if this is your first time designing a properly segmented network - you will spend some time debugging things that break.
2)Can I just create Vlans and leave all these Vlans in the same laye 3 network so that they can go out of the network (I am not not concerned about Vlan routing) or I have to create subnets which means reconfiguring the existing devices (something I do not want)
Can you? Yes.
Will it buy you anything in terms of security? Not really.
Will it make the entire project 10 times harder? Absolutely.
Should you design a network this way? NO.
I think you would do well to think about why you might use VLANs to begin with.
It sounds like you have reasons to limit / segment traffic, but I would question if you're really going to do the homework necessary to build ACLs to have fine-grained control of traffic between PCs, servers, and printers. In every case that I've seen that done the admin ends up giving up and just opening all traffic (allow ip any any) between the "server VLAN" and the "workstation VLAN" because they can't get software vendors to disclose what ports / protocols are necessary to make applications work (or because the applications use dynamic ports that aren't handled by protocol handlers in the inter-VLAN router).
The typical trade-off between using a layer 3 switch versus a more router-like device like a Cisco ASA is expressiveness of the ACL system versus routing performance. A layer 3 switch can typically route at wire-speed, however it may not support ACLs with enough expressiveness to do what you need. In some cases, the layer 3 switch ACL system does have the expressiveness, but using those expressive features may cause routing to move through a CPU rather than an ASIC, diminishing performance.
I'd start by building a list of the ACLs I intend to have, then evaluating if they layer 3 switches are capable of handling them and, if they are, keeping the traffic in a "fast path" while doing so. You'll get the highest performance routing in the layer 3 switches, but (particularly with your guest wifi VLAN) the ASA may be a better fit from a rule expressiveness perspective.
Insofar as your printers go: If you're looking to limit access to the printers to only authorized administrators and the servers queuing them then you may want to throw them into a VLAN. Some people are fine with printers being directly accessible by client computers, but other environments (where the printed items are of a sensitive nature, or where billing software needs to arbitrate access to the printers) benefit from isolating the printers and strictly limiting the hosts that can connect to them. You'll have to gauge your needs there. How much accountability do you need w/ respect to auditing print jobs, for example?
Best Answer
my first guess, assuming the subnet for VLAN1 was around prior and the next hop above the L3 switches is the firewall, is that your firewall doesn't have routes back to the new VLAN subnets. Check your internal routing, see if you get ping responses all the way up and down the routing chain, etc.
Verify routing between the switches and their gateway, verify routing between a client and the firewall, etc.
Now if you have a more complex setup with proxies, or additional routing layers then you'll need to post a pic of your network for more assistance.