simon3z / virt-deploy Goto Github PK

License: GNU General Public License v2.0

Python 100.00%

virt-deploy's Introduction

Easily Deploy Virtual Machines

Virt-deploy is a python library to standardize the deployment of virtual machines. It currently supports libvirt and takes advantage of virt-builder and virt-install to automate the creation of templates and instances.

usage: virt-deploy [-h] [-v]
                   {create,start,stop,delete,templates,address,ssh} ...

positional arguments:
  {create,start,stop,delete,templates,address,ssh}
    create              create a new instance
    start               start an instance
    stop                stop an instance
    delete              delete an instance
    templates           list all the templates
    address             instance ip address
    ssh                 connects to the instance

optional arguments:
  -h, --help            show this help message and exit
  -v, --version         show program's version number and exit

Creation of an Instance

To create a new vm instance based on a fedora-21 template:

# virt-deploy create instance01 fedora-21

The fedora-21 template image will be downloaded (virt-builder), and prepared to be used (virt-sysprep). This is done only once when the template is used for the first time.

The instance is then created with some customization such as random root password and the hostname. All the information are then summarized when the creation is completed:

name: vm-test01-fedora-21-x86_64
root password: xxxxxxxxxx
mac address: 52:54:00:xx:xx:xx
hostname: vm-test01
ip address: 192.168.122.xxx

Storage and Network Management

Virt-deploy uses the 'default' libvirt storage pool and network. Images are created in the pool path and hostnames and ip addresses are assigned and registered in the network definition.

Building from Sources

At the moment the suggested procedure to build from sources is to produce rpms with the proper packages requirements (virt-builder and virt-install):

$ python setup.py sdist
$ sudo dnf builddep virt-deploy.spec
$ rpmbuild -ta dist/virt-deploy-<version>.tar.gz

If you're a yum user (centos and fedora < 21) then you should use yum instead of dnf:

$ sudo yum-builddep virt-deploy.spec

virt-deploy's People

Contributors

Stargazers

Watchers

Forkers

david-caro jscotka zakiva enoodle pombredanne rarguello yaacov lyarwood mmorency2021

virt-deploy's Issues

better handle table _IMAGE_OS_TABLE

Hi,
I found issue, that I have own virt-builder repo with teplates.
Iti s okay in case I have there fedora-21 and similar,
But in case I have there distro like
fedora-22 or another name for fedora-21 like: fedora21-cockpit
it leads to problem with code:
'--os-variant', _get_image_os(template),

Now I patched that table et the begin of file, but better solution is to use some mapping to some older one:
like if you don't know that (it means not in table and also libvirt does not know that) map it to for example fedora20
or another possibility is to add option to force use some version for --os-variant
Regards
Honza

RFE: add new option to wait for guest is ready to communicate (ping, ssh, ...)

Hi,
I had to done my own workaround around function, what wait until machine is started (ssh is ready to communicate) https://github.com/jscotka/cockpit/blob/new_test_structure/test/tests/lib/create_test_machine.sh#L93
It would be nice to add param to virt-deploy start command (what will wait until for example ping, or ssh is working) or second solution is to write dedicated function for that like my vm_wait_online

see actual results (first 11 pings are lost because machine is not booted well):

[root@unused-4-228 tests]# virt-deploy stop $NAME
[root@unused-4-228 tests]# virt-deploy start $NAME; ping -c 15 $IP
PING 192.168.122.35 (192.168.122.35) 56(84) bytes of data.
64 bytes from 192.168.122.35: icmp_seq=12 ttl=64 time=0.218 ms
64 bytes from 192.168.122.35: icmp_seq=13 ttl=64 time=0.148 ms
64 bytes from 192.168.122.35: icmp_seq=14 ttl=64 time=0.194 ms
64 bytes from 192.168.122.35: icmp_seq=15 ttl=64 time=0.262 ms

--- 192.168.122.35 ping statistics ---
15 packets transmitted, 4 received, 73% packet loss, time 13999ms
rtt min/avg/max/mdev = 0.148/0.205/0.262/0.043 ms

virt-deploy ssh $NAME works only in case starting is enought fast (there is some limit for ssh what cause that this function now works as expected). I can imagine situation, that there will be some long startup -> what causes that calling this function fails

RFE: tree installation abilities

Hi,
Now there are precreated images for virt-deploy. For some reason it would be nice to have also possibility to do fresh installation via template from os tree like http://download.fedoraproject.org/pub/fedora/linux/releases/21/Server/x86_64/os:

generate kickstart for machine (via template like setup variables)
usecase is:
I would like to have machine created for exact snapshot
not needed to download basic image
Test of installation
prepare machine for special puroposes.
local(nearest) mirror of installation trees

In case it is not part of project , it isn't problem. It would be another possibility of installation in case for example you have only generic os tree of fedora/centos for installation.
Thansk&Regards
Honza

NUMBER=2
TREE="http://download.fedoraproject.org/pub/fedora/linux/releases/21/Server/x86_64/os"

TREE="http://ftp.fi.muni.cz/pub/linux/centos/7.0.1406/os/x86_64/"

KSF=base.ks
ADIR=pwd
VMDIRS=/var/lib/libvirt/images/
mkdir -p $VMDIRS
NAME=test$NUMBER
IMG=$NAME.img
MAC=52:55:00:81:ee:1$NUMBER

qemu-img create -f qcow2 $VMDIRS/$IMG 20G
virt-install --connect=qemu:///system
--network network:default,mac=$MAC
--initrd-inject=$ADIR/lib/$KSF
--extra-args="ks=file:/$KSF
console=tty0 console=ttyS0,115200"
--name=$NAME
--disk $VMDIRS/$IMG
--ram 1028
--vcpus 1
--check-cpu
--accelerate
--hvm
--location $TREE
--nographics

virt-deploy should depend on python-lxml

Otherwise:

Traceback (most recent call last):
  File "<string>", line 2, in <module>
  File "/usr/lib/python2.7/site-packages/virtdeploy/__init__.py", line 38, in get_driver
    return get_driver_class(name)(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/virtdeploy/__init__.py", line 33, in get_driver_class
    module = __import__(DRIVERS[name][0], globals(), locals(), name, 1)
  File "/usr/lib/python2.7/site-packages/virtdeploy/drivers/libvirt.py", line 30, in <module>
    from lxml import etree
ImportError: No module named lxml

support creation machines for user (qemu:///session)

Hi,
It seems that virt-deploy nowadays support only root (system) VMs
qemu:///system

I'm expecting that it should possible to also create/handle user (session) VMs:
via qemu:///session
My question is, is it possible now somehow (some config) or it is not supported anyway and is it possible to add this possibilities.
Thanks&Regards
Honza

So the default storage pool must exist? Why?

So the default storage pool must exist? Why? I create all my storage pools, they are all on proper SAN, iSCSI, etc. on true storage frames. So the need for a local (host) path for storage is, frankly useless, and well, confusing if it exists. But apparently virt-deploy demands it exists? I don't get it. And virt-manager has the same issue? You can remove it, but it 'magically' reappears?

storage pool in /var/lib/libvirt/images without sudo

I have my system configured so that I can use virsh with qemu:///system by way of:

LIBVIRT_DEFAULT_URI=qemu:///system

So generally speaking I can do all virsh commands including start VMs without having to use sudo or authenticate otherwise.

I have a storage pool called images and virsh list --all shows me the volumes in that storage pool. vagrant up is unable to create it's VMs there however giving me an error about not being able to find the storage pool.

I resolved that by doing a chmod 777 /var/lib/libvirt/images/ (purely as a test -- I don't want to leave it that way) but do question the validity of having to do this.

Why is it that I can start VMs using virsh from that storage pool but Vagrant cannot manage to use it?

Is this because Vagrant-libvirt wants to create the disks-as-snapshots in /var/lib/libvirt/images and uses the permission as the calling user to do so? If so, doesn't libvirt provide a better method than just manipulating directory permissions so that the calling user can write into that directory directly?

Vagrant seems to use sudo for other things, why not this?

error when default storage pool is missing

my work laptop is rhel 6.5
I have created f21 VM (named miqbuild.rhs)
from the f21 VM I have successfully performed these commands:
dnf copr enable fsimonce/virt-deploy
dnf install virt-deploy virt-address
Now when I try to create the instance, I get this:

[root@miqbuild ~]# virt-deploy create test01 fedora-21
Traceback (most recent call last):
File "/usr/bin/virt-deploy", line 9, in
load_entry_point('virt-deploy==0.1.6', 'console_scripts', 'virt-deploy')()
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 143, in main
return parse_command_line(sys.argv[1:])
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 138, in parse_command_line
return COMMAND_TABLEargs.command
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 41, in instance_create
instance = driver.instance_create(args.id, args.template)
File "/usr/lib/python2.7/site-packages/virtdeploy/drivers/libvirt.py", line 96, in instance_create
pool = conn.storagePoolLookupByName(kwargs['pool'])
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4305, in storagePoolLookupByName
if ret is None:raise libvirtError('virStoragePoolLookupByName() failed', conn=self)
libvirt.libvirtError: Storage pool not found: no storage pool with matching name 'default'

Any idea what I'm missing at this point, or maybe my approach is completely wrong?

error when deleting created instance (more snapshots)

Hi,
unable to delete domain althought it was created by virt deploy.
It seems that it is that I'm using avocado testing framework with virtual plugin, what have parameter --vm-cleanup -> restore machine after test (probably creates snapshots) http://avocado-framework.readthedocs.org/en/latest/VirtualMachinePlugin.html#vm-plugin-basics

so that next command fais (I think it could be solved in virt-deploy, to deal with created snapshots and delete also them):

$ sudo virt-deploy delete $NAME
Traceback (most recent call last):
File "/bin/virt-deploy", line 9, in
load_entry_point('virtdeploy==0.1.5', 'console_scripts', 'virt-deploy')()
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 135, in main
return parse_command_line(sys.argv[1:])
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 130, in parse_command_line
return COMMAND_TABLEargs.command
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 58, in instance_delete
return driver.instance_delete(args.name)
File "/usr/lib/python2.7/site-packages/virtdeploy/drivers/libvirt.py", line 262, in instance_delete
dom.undefine()
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2577, in undefine
if ret == -1: raise libvirtError ('virDomainUndefine() failed', dom=self)
libvirt.libvirtError: Requested operation is not valid: cannot delete inactive domain with 2 snapshots

error: failed to mkdir on virt-deploy create <instance> <image>

[root@miqbuild ~]# virt-deploy create test01 fedora-21
virt-builder: warning: cache /root/.cache/virt-builder:
Unix.Unix_error(Unix.ENOENT, "mkdir", "/root/.cache/virt-builder")
virt-builder: warning: disabling the cache
[ 1.0] Downloading: http://libguestfs.org/download/builder/fedora-21.xz

################################################################## 100.0%

[ 205.0] Planning how to build this image
[ 205.0] Uncompressing
/tmp/vbcachec07622.txt: Success
virt-builder: error: internal error: invalid argument: some threads failed,
see earlier errors

If reporting bugs, run virt-builder with debugging enabled and include the
complete output:

virt-builder -v -x [...]
Traceback (most recent call last):
File "/usr/bin/virt-deploy", line 9, in
load_entry_point('virt-deploy==0.1.6', 'console_scripts', 'virt-deploy')()
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 143, in main
return parse_command_line(sys.argv[1:])
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 138, in parse_command_line
return COMMAND_TABLEargs.command
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 41, in instance_create
instance = driver.instance_create(args.id, args.template)
File "/usr/lib/python2.7/site-packages/virtdeploy/drivers/libvirt.py", line 105, in instance_create
base = _create_base(template, kwargs['arch'], repository)
File "/usr/lib/python2.7/site-packages/virtdeploy/drivers/libvirt.py", line 264, in _create_base
'--root-password', 'locked:disabled'))
File "/usr/lib/python2.7/site-packages/virtdeploy/utils.py", line 36, in execute
raise subprocess.CalledProcessError(p.returncode, args)
subprocess.CalledProcessError: Command '('virt-builder', 'fedora-21', '-o', '/var/lib/libvirt/images/_fedora-21-x86_64.qcow2', '--size', '20G', '--format', 'qcow2', '--arch', 'x86_64', '--root-password', 'locked:disabled')' returned non-zero exit status 1

CentOS 7.2 not supported

CentOS 7.2 is not supported yet.

fedora-23 template: virt-resize: error: unknown/unavailable method for expanding the xfs filesystem on /dev/sda3

No idea if this is virt-deploy's fault, but creating a fedora-23 fails reproducibly:

$ sudo virt-deploy create miq1 fedora-23
[   2.0] Downloading: http://libguestfs.org/download/builder/fedora-23.xz
[   3.3] Planning how to build this image
[   3.3] Uncompressing
[  33.5] Resizing (using virt-resize) to expand the disk to 20.0G
virt-resize: error: unknown/unavailable method for expanding the xfs 
filesystem on /dev/sda3

If reporting bugs, run virt-resize with debugging enabled and include the 
complete output:

  virt-resize -v -x [...]
Traceback (most recent call last):
  File "/bin/virt-deploy", line 9, in <module>
    load_entry_point('virt-deploy==0.1.7', 'console_scripts', 'virt-deploy')()
  File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 154, in main
    return parse_command_line(sys.argv[1:])
  File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 149, in parse_command_line
    return COMMAND_TABLE[args.command](args)
  File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 43, in instance_create
    instance = driver.instance_create(args.id, args.template)
  File "/usr/lib/python2.7/site-packages/virtdeploy/drivers/libvirt.py", line 106, in instance_create
    base = _create_base(template, kwargs['arch'], repository)
  File "/usr/lib/python2.7/site-packages/virtdeploy/drivers/libvirt.py", line 265, in _create_base
    '--root-password', 'locked:disabled'))
  File "/usr/lib/python2.7/site-packages/virtdeploy/utils.py", line 40, in execute
    raise subprocess.CalledProcessError(p.returncode, args)
subprocess.CalledProcessError: Command '('virt-builder', 'fedora-23', '-o', '/var/lib/libvirt/images/_fedora-23-x86_64.qcow2', '--size', '20G', '--format', 'qcow2', '--arch', 'x86_64', '--root-password', 'locked:disabled')' returned non-zero exit status 1

Works fine with centos-7.1 template.

I'm running this on a Fedora 23 x86_64 desktop, with virt-deploy from rpm copr.

Support cloud-init to configure instances

Add support for cloud-init. The support will probably have to be implemented in each driver.

traceback when using same name (DNS) -> no info about created machine displayed

Hi,
I've created machine via:

virt-deploy teste fedora-21

Then I've removed machine via virt-manager (delete) that created guest
next command with same name:

virt-deploy teste fedora-21

thows traceback althoung machine is probably properly created (this traceback should be suppressed):
libvirt.libvirtError: Requested operation is not valid: there is already at least one DNS HOST record with a matching field in network default

But it causes that info about machine is not displayed , so that I dont know root password
name: teste-fedora-21-x86_64
root password: testvm
mac address: 52:54:00:43:98:d6
hostname: localhost
ip address: 1.1.1.1

  Regards
  Honza

Traceback (most recent call last):
File "/bin/virt-deploy", line 9, in
load_entry_point('virtdeploy==0.1.5', 'console_scripts', 'virt-deploy')()
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 135, in main
return parse_command_line(sys.argv[1:])
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 130, in parse_command_line
return COMMAND_TABLEargs.command
File "/usr/lib/python2.7/site-packages/virtdeploy/cli.py", line 37, in instance_create
instance = driver.instance_create(args.id, args.template)
File "/usr/lib/python2.7/site-packages/virtdeploy/drivers/libvirt.py", line 190, in instance_create
_add_network_host(net, hostname, ipaddress)
File "/usr/lib/python2.7/site-packages/virtdeploy/drivers/libvirt.py", line 300, in _add_network_host
_NET_UPDATE_FLAGS)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2867, in update
if ret == -1: raise libvirtError ('virNetworkUpdate() failed', net=self)
libvirt.libvirtError: Requested operation is not valid: there is already at least one DNS HOST record with a matching field in network default

virt-deploy should require new enough libguestfs-tools-c version

I got this:

Traceback (most recent call last):
  File "<string>", line 2, in <module>
  File "/usr/lib/python2.7/site-packages/virtdeploy/drivers/libvirt.py", line 105, in instance_create
    base = _create_base(template, kwargs['arch'], repository)
  File "/usr/lib/python2.7/site-packages/virtdeploy/drivers/libvirt.py", line 264, in _create_base
    '--root-password', 'locked:disabled'))
  File "/usr/lib/python2.7/site-packages/virtdeploy/utils.py", line 31, in execute
    p = subprocess.Popen(args, stdout=stdout, stderr=stderr, cwd=cwd)
  File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1308, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

I think it tries to run virt-builder here.

It went away after updating libguestfs-tools-c from 1.22.6 to 1.28.1, so I guess virt-builder wasn't in my old version.

Add support for specifying ssh commands to execute on an instance

Hi,
It would be nice, to have some possibilies to do some postinstallation commands on created guest.
Typycal usecase is similar like section %post in kickstart files, do some initialization steps, before machine starts (like: * add ssh keys * setup repositories * install additiona packages * setup mount)

I could imagine two ways how to do it:

add it to template files for guest creation, like
[fedora21]
script = "yum install screen
cat "ssh-rsa AAAAB3NzaC1yc2E... root@localhost" >> /root//.ssh/authorized_keys
"
or on command line when creating instance like:

virt-deploy create instance01 fedora-21 --commad "yum install screen; cat "ssh-rsa AAAAB3NzaC1yc2E... root@localhost" >> /root//.ssh/authorized_keys"

Thanks&Regards
Honza

RFE: create new instance with option to modify used network

Hi,
Now when creating new instances like: virt-deploy create f fedora-21
I'm unable to modify used network (it is created under default network)
It would be nice to have some option like --network=[default,...] to choose network definition file for usage and modifiing.
Usecase is: I would like to chnage network parameteres and affecting default network is not good option. (like add domain name, create it in various ways, and do not break created default virsh network)

Thanks&Regards
Honza

simon3z / virt-deploy Goto Github PK

virt-deploy's Introduction

Easily Deploy Virtual Machines

Creation of an Instance

Storage and Network Management

Building from Sources

virt-deploy's People

Contributors

Stargazers

Watchers

Forkers

virt-deploy's Issues

TREE="http://ftp.fi.muni.cz/pub/linux/centos/7.0.1406/os/x86_64/"

################################################################## 100.0%

virt-deploy teste fedora-21

virt-deploy teste fedora-21

virt-deploy create instance01 fedora-21 --commad "yum install screen; cat "ssh-rsa AAAAB3NzaC1yc2E... root@localhost" >> /root//.ssh/authorized_keys"

Recommend Projects

Recommend Topics

Recommend Org