01-25-2018
Hi,
I think OpenVZ 7 (the latest release) does support Windows, though only running in a KVM VM and not in a container. OpenVZ 7 added the option to create VMs that was previously only available in Virtuozzo, and so you can create containers for Linux guests and VMs for all non-Linux guests on OpenVZ 7 (or you should be able to at least, according to the documentation I can see). So if you're familiar with OpenVZ, then OpenVZ 7 is probably the best way to go, since you can use both containers and full-blown real VMs on the same host.
However, if the issue here is that you are actually wanting to make day-to-day use of your own PC whilst being able to run containers and VMs on it (which I think might be what your comments about SmartOS imply), then your options are a bit more limited. Things like OpenVZ/SmartOS/ESX are meant to run on a dedicated server that does nothing but host containers and VMs. You then connect remotely to those containers and VMs to use them in whatever way you see fit (SSH, rdesktop, etc), and can also connect remotely to the hardware node to manage it.
If you're looking to be setting up VMs or containers on your own PC, then running a normal desktop-oriented Linux distro locally and using KVM/QEMU to run VMs on it might be a good way forward. Similarly you could run Windows 10 or Windows Server locally and add the Hyper-V role, and create VMs that way whilst still having a usable "real" desktop OS too. Or just use VirtualBox or something like that if your needs are simpler.
4 More Discussions You Might Find Interesting
1. Solaris
Hello- On Solaris 10g x86 - I had two IP addresses , one for unix host (connecting through putty) and one for ILOM (connecting through CLI and web). I had to perform some changes in FS sizes etc, did that on unix host and executed command 'init 6' remotely for them to take place. But, the unix host... (30 Replies)
Discussion started by: panchpan
30 Replies
2. Red Hat
On Monday March 30, Intel announced the availability of their much anticipated new line of processors, the Intel® Xeon® Processor 5500 series–nicknamed Nehalem.
Red Hat, a long-time partner of the market-leading chip maker , collaborated on the chip’s debut, testing and optimizing the... (0 Replies)
Discussion started by: Linux Bot
0 Replies
3. UNIX for Dummies Questions & Answers
Hi all,
I have a small Question here in Unix File System.I am unable to get a proper answer in Internet. Hope someone can get back to me soon.
A Unix file system can mount filesystem of several disk partitions to form a single global space.
Suppose that you wish to virtualize this global... (1 Reply)
Discussion started by: Pavan Kumar
1 Replies
4. Red Hat
Hello guys!
First of all sorry about my english.
I am using KVM to virtualizate. But when i run the virt-install command, it shows the next error:
ERROR Host does not support any virtualization options.My server had virtualisation extensions enabled in the bios.
It is my first time using... (7 Replies)
Discussion started by: morrison71
7 Replies
LEARN ABOUT DEBIAN
vzmigrate
vzmigrate(8) Containers vzmigrate(8)
NAME
vzmigrate - migrate a container between two OpenVZ servers
SYNOPSIS
vzmigrate [-r|--remove-area yes|no] [--ssh=ssh_options] [--rsync=rsync_options] [--keep-dst] [--online] [-v] destination_address CTID
DESCRIPTION
This utility is used to migrate a container from one (source) Hardware Node (HN) to another (destination) HN. The utility can migrate
either stopped or running container. For a stopped container, simple CT private area transfer is performed (rsync(1) is used for file
transfer). For running containers, migration may be offline (default) or online.
This program uses ssh as a transport layer. You will need to put ssh public key to destination node and be able to connect to node without
entering password.
OPTIONS
-r, --remove-area yes | no
Whether to remove a container area on source HN for the successfully migrated container. Default is yes.
--ssh=options
Additional options that will be passed to ssh while establishing connection to destination HN.
--rsync=options
Additional options that will be passed to rsync(8). You may add options like -z to enable data compression if you are migrating
over a slow link.
--keep-dst
Do not clean synced destination container private area in case of some error. It makes sense to use this option on big container
migration to avoid syncing container private area again in case some error (on container stop for example) occurs during first
migration attempt.
--online
Perform online (zero-downtime) migration: during the migration the container hangs for a while and after the migration it continues
working as though nothing has happened.
-v Verbose mode. Causes vzmigrate to print debugging messages about its progress. Multiple -v options increase the verbosity. The
maximum is 3.
EXAMPLES
Migration of CT 101 to 192.168.1.130 with downtime:
vzmigrate 192.168.1.130 101
Online migration of CT 102 to 192.168.1.130:
vzmigrate --online 192.168.1.130 102
EXIT STATUS
0 EXIT_OK
Command completed successfully.
1 EXIT_USAGE
Bad command line options.
2 EXIT_VE_STOPPED
Container is stopped.
4 EXIT_CONNECT
Can't connect to destination (source) HN.
6 EXIT_COPY
Container private area copying/moving failed.
7 EXIT_VE_START
Can't start or restore destination CT.
8 EXIT_VE_STOP
Can't stop or checkpoint source CT.
9 EXIT_EXISTS
Container already exists on destination HN.
10 EXIT_NOTEXIST
Container does not exists on source HN.
12 EXIT_IP_INUSE
You attempt to migrate CT which IP address(es) are already in use on the destination node.
13 EXIT_QUOTA
Operation with CT quota failed.
SEE ALSO
rsync(1).
COPYRIGHT
Copyright (C) 2001-2010, Parallels, Inc. Licensed under GNU GPL.
OpenVZ 28 Jun 2011 vzmigrate(8)