so that callers of startVM in LibvirtComputingResource know that a vm failed
to start
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1366224775 -0600
pools the proper way won't cause problems for KVM HA Monitor, this patch closes
holes. Call the KVMStoragePool deleteStoragePool that properly removes it from
the KVMHA hashmap, instead of the pools direct delete() call.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1366172318 -0600
- Supports DHCP, Source NAT, Static NAT, Firewall rules, Port Forwarding
- Renamed MidokuraMidonet to MidoNet
- Related Jira ticket is CLOUDSTACK-996
Signed-off-by: Dave Cahill <dcahill@midokura.com>
Signed-off-by: Hugo Trippaers <htrippaers@schubergphilis.com>
deleted NFS pools, causing failures when defining new storage pools. Sometimes
a storage pool has never been used on a host, and getStoragePool fails when
copying templates or in storage migration. deleteStoragePool(pool) often fails
silently, leaving no pool defined in libvirt, but a mountpoint left behind.
This patch handles some of these exceptions and brings forward any issues via
logging.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1364603486 -0600
KVM to manager. This adds collection of available storage to KVM, not
just used.
Bugfix-for: 4.0.2, 4.1, master
Submitted-by: Ted Smith <darnoth@gmail.com>
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1363966235 -0600
The collection of network usage from VPC virtual router on KVM does not work,
because there is no corresponding procedure to deal with VPC virtual router
(cmd.isForVpc() = true).
Reviewed-by: Kishan Kavala <kishan@apache.org>
Reported-by: Wei Zhou <w.zhou@leaseweb.com>
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
cloud-defined resources on the host has caused various problems. As a backward
compatible fix, if an existing pool with a different name collides with a pool
being created (by path), the pool will be redefined with the name cloudstack
knows about. This is actually what brought up the bug, a persisted storage pool
cloudstack wasn't managing.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1363210149 -0600
Detail: When we stop a VM, it's definition is no longer valid. Therefore, we
need to catch the exception thrown from libvirt in trying to lookup a
non-existent domain by UUID while trying to check if it's shut down.
BUG-ID:CLOUDSTACK-600
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1363201066 -0600
Detail: A previous patch fixed an issue where we are defining VMs to persist
locally on KVM hosts, which can cause issues if the agent isn't running and
libvirt decides to start the VM unbeknownst to cloudstack. The previous patch
stopped defining VMs as persistent. This patch adds compatibility for existing
cloudstack environments, removing the persistent definition on stop if needed.
BUG-ID: CLOUDSTACK-600
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1363194656 -0600
Detail: This gets rid of the patchdisk method of passing cmdline and
authorized_keys to KVM system VMs. It instead passes them to a virtio socket,
which the KVM guest reads from the character device /dev/vport0p1 during
cloud-early-config. Tested to work on CentOS 6.3 and Ubuntu 12.04. Should
work with even older versions of libvirt.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1362691685 -0700
Current kvm agent will silently ignore many exception, and there's no
way to see what really happened. This patch will log in trace level log
that was silently ignored. And also, it will fix huge bare Exception
catch, which is very harmful because it also catches RuntimeException.
Detail: This device can be used for remotely controlling the system vms through
a local socket on the host. We will attempt to replace the KVM patchdisk with
it. Tested, successfully deploys VM, and if system vm has proper driver it
will create a /dev/vport0p1 device within the VM. We will be updating the
system VM in 4.2/5.0 and will support this.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1362527352 -0700
Libvirt-java 0.4.9 works just fine with JNA 3.2.4 which is in
all distributions.
Future libvirt version require at least JNA 3.5.1 due to new methods
and memory management, but that is not our concern now.
By depending on the JNA in the distribution and adding it to the classpath
we can work just fine.
- Building map of {trafficType, vifDriver} at configure time
- Use the relevant VIF driver for the given traffic type when call plug()
- Inform all vif drivers when call unplug(), as we no longer know traffic type
- Refactor VIF driver choosing code and add unit tests
- Basic unit tests, just test default case
- Also slight refactor of unit test code, and use jUnit 4 instead of 3, to match rest of codebase
Signed-off-by: Hugo Trippaers <htrippaers@schubergphilis.com>
Some concepts included:
* the replace.properties location used by maven is parameterized to allow
for a build that does not modify the currently git tracked files
* package naming is updated along the lines of what was discussed on the
-dev mailing list and between committers at the Build a Cloud Day in Belgi
* package version pattern is updated (since we redo all package names,
we might as well drop the epoch)
The recently added overcommit feature breaks compatibility between older management servers
and 4.2 agents.
This patch fixes that by falling back if needed.
Detail: Removing references to /usr/lib/cloud and /usr/lib64/cloud so that old
systemvm.iso files aren't found by accident. systemvm.iso should exist in
/usr/share/cloudstack-common/vms now.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1360860243 -0700
Detail: If your traffic label points to a bridge that is on a tagged interface
rather than a real physical interface, cloudstack may not parse the physical
interface correctly, bringing up tagged interfaces on the tagged interface.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1360798665 -0700
We used to define domains persistent in libvirt, which caused XML definitions
to stay there after a reboot of the hypervisor.
We however don't do anything with those already defined domains, actually, we wipe
all defined domains when starting the agent.
Some users however reported that libvirt started these domains after a reboot
before the CloudStack agent was started.
By starting domains from the XML description and not defining them we prevent
them from ever being stored in libvirt.
