[PR] Bump chart for new provider release v1.1.0 [cloudstack-kubernetes-provider]

2024-05-10 Thread via GitHub


hrak opened a new pull request, #61:
URL: https://github.com/apache/cloudstack-kubernetes-provider/pull/61

   Bump chart for new provider release v1.1.0


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Bump chart for new provider release v1.1.0 [cloudstack-kubernetes-provider]

2024-05-10 Thread via GitHub


hrak closed pull request #61: Bump chart for new provider release v1.1.0
URL: https://github.com/apache/cloudstack-kubernetes-provider/pull/61


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[PR] Minor corrections [cloudstack-documentation]

2024-05-10 Thread via GitHub


andrijapanicsb opened a new pull request, #400:
URL: https://github.com/apache/cloudstack-documentation/pull/400

   (no comment)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Migrate VMware VM to KVM improvement documentation [cloudstack-documentation]

2024-05-10 Thread via GitHub


andrijapanicsb commented on code in PR #388:
URL: 
https://github.com/apache/cloudstack-documentation/pull/388#discussion_r1596569789


##
source/adminguide/virtual_machines/importing_vmware_vms_into_kvm.rst:
##
@@ -108,8 +108,9 @@ Converting and importing a VMware VM
 
 When importing a Virtual Machine from VMware to KVM, CloudStack performs the 
following actions:
 
-- Cloning the Source Virtual Machine on the selected VMware Datacenter: 
The source Virtual Machine will be cloned in the original state (running or 
stopped for Linux VMs, or stopped for Windows VMs). The recommended state is 
the stopped state to prevent data inconsistencies or loss when cloning the 
virtual machine.
-- Converting the Cloned Virtual Machine to KVM using virt-v2v: CloudStack 
(or the administrator) selects a running and Enabled KVM host to perform the 
conversion from VMware to KVM using **virt-v2v**. If the binary is not 
installed, then the host will fail the migration. In case it is installed it 
will perform the conversion into a temporary location (which can be selected by 
the administrator) to store the converted QCOW2 disks of the virtual machine. 
The disks are then moved into the destination storage pools for the virtual 
machine. The conversion is a long-lasting process which can be set to time out 
by the global setting 'convert.vmware.instance.to.kvm.timeout'. The conversion 
processes take a long time because virt-v2v creates a temporary virtual machine 
to inspect the source VM and generate the converted disks with the correct 
drivers. Additionally, it needs to copy the converted disks into the temporary 
location.
+- Clones the Source Virtual Machine on the selected VMware Datacenter: The 
source Virtual Machine will be cloned in the original state (running or stopped 
for Linux VMs, or stopped for Windows VMs). The recommended state is the 
stopped state to prevent data inconsistencies or loss when cloning the virtual 
machine.
+- Exports the OVA from the Cloned Virtual Machine to a temporary location 
(which can be selected by the administrator).
+- Converts the OVA on the temporary location to KVM using virt-v2v: 
CloudStack (or the administrator) selects a running and Enabled KVM host to 
perform the conversion from VMware to KVM using **virt-v2v**. If the binary is 
not installed, then the host will fail the migration. In case it is installed 
it will perform the conversion into the temporary location to store the 
converted QCOW2 disks of the virtual machine. The disks are then moved into the 
destination storage pools for the virtual machine. The conversion is a 
long-lasting process which can be set to time out by the global setting 
'convert.vmware.instance.to.kvm.timeout'. The conversion processes takes a long 
time because virt-v2v creates a temporary virtual machine to inspect the source 
VM and generate the converted disks with the correct drivers. Additionally, it 
needs to copy the converted disks into the temporary location.

Review Comment:
   "selects a running and Enabled KVM host to perform the conversion"
   This comment comes after some consultancy work, hopefully not too late...
   
   @sureshanaparti are there checks for this - i.e. do we support a scenario 
where cloud operator might have many Ubuntu 22.04 hosts, but want to use a 
(few) EL9 host (which has a much newer virt-v2v version than the Ubuntu 22.04, 
and thus much better conversion success than virt-v2v on Ubuntu hosts) for the 
conversion while ensuring that new VMs are not being regularly deployed on 
those EL9 hosts? (i.e. it would be good that admin can choose even a disabled 
host, or at least a host (Enabled, EL9), which exists in a DISABLED CLUSTER - 
is this possible?)
   
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org