Re: Unable to create a deployment for VM
Hello dear list,
@Andrija @Yordan thanks for these insightful informations! I did check with
attention pieces of information you brought up about my setup. I am still
sticking with XenServer because I feel It is more appealing for me.
Applying your precious information I got rid of previous misconfigured
setting but still get stuck with my a bit old shapeblue "build a virtual
environment test with VirtualBox" because of HVM which is, I guess, a
mandatory feature since XenServer7.5 and recent hotfixes.
I am saying that because it looks nowadays, to contain a Meltdown-spectre
attack from a guest VM, CS architecture dictates the use of HVM for system
VMs .and that makes the usual below command quite useless:
mysql -p[password] [account] -e \ "INSERT INTO cloud.configuration
> (category, instance, component, name, value, description) VALUES
> ('Advanced', 'DEFAULT', 'management-server', '*xen.check.hvm*', '*false*',
> 'Shoud we allow only the XenServers support HVM');"
Despise the use of the disabled flag for HVM in my templates and
everything, I still have in my logs:
2018-10-27 01:17:50,744 DEBUG [c.c.h.x.r.w.x.CitrixStartCommandWrapper]
> (DirectAgent-3:ctx-a86f4b56) (logid:a337009d) 1. *The VM v-328-VM is in
> Starting state*.
> 2018-10-27 01:17:50,747 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-3:ctx-a86f4b56) (logid:a337009d) no guest OS type, *start it
> as HVM guest*
>
and systemVMs still refusing to boot with:
2018-10-27 01:17:54,340 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-10:ctx-e406da5d) (logid:512ff438) *Task failed! Task record:*
> uuid: d910a1bc-9801-b017-eafe-b3d03768aae1
>nameLabel: Async.VM.start_on
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Sat Oct 27 01:17:52 CEST 2018
> finished: Sat Oct 27 01:17:52 CEST 2018
> status: failure
> residentOn: com.xensource.xenapi.Host@32106b38
> progress: 1.0
> type:
> result:
>errorInfo: [*VM_HVM_REQUIRED*,
> OpaqueRef:44a24e77-39a5-472c-af8a-d7607e57714a]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
>
I am writing you here to know if there is a workaround to keep using
virtualbox as an working environment for Xenserver7.5 with CS 4.11 ?
Since Virtuabox does not plan to support HVM by any means, is it still
doable running a recent CS + Xen with that software, what are my options ?
- Can I downgrade to XenServer 6.5 and still use CS4.11.1 ?
- Would the removal of every Xen hotfixes (XS75E001 XS75E002 XS75E003
XS75E004 XS75E005) make systemVMs launchable ?
- Would the building of my own system Templates makes the situation better ?
Does XenServer7.5 implement HVM as a die-hard, not deactivable feature, or
can i work around?
thanks you for your attention
PS please find my recent management log attached
Le mer. 24 oct. 2018 à 23:41, fulc927 a écrit :
> Hello,
>
> First my environment is built following this tutorial
> https://www.shapeblue.com/virtualbox-test-env/
>
> I am trying to setup properly Cloudstack as a proof-of-concept and
> eventually adopting it in more sophisticated configuration
>
> I am using cloudstack-management-4.11 and Citrix XenServer Host 7.5.0
>
> I successfully create a zone and a primary storage, bad things are
> coming next, once SystemVMs have to boot.
>
> System VMs nevers successfully boot, they are stuck in an endless loop
> cycle (start-stop-start…)
>
> logs attached to this email report:
>
> > Deploy avoids pods: null, clusters: null, hosts: null
> > Unable to create a deployment for VM
>
> My config has enough ressources to run the management server and the xen
> one in an virtualyzed environment
>
> I highly suspect a network misconfiguration, everything should be OK
> since i replicate the config from shapeblue:
>
> PRI STORAGE 10.10.100.11
>
> SECONDARY STORAGE 10.10.101.11
>
> MGMT TRAFFIC SERVER 192.168.56.11
>
> XEN 192.168.56.101
>
> POD SETTINGS 192.168.56.1 (21 - 30)
>
> PUBLIC TRAFFIC 172.30.0.(21 - 30 )
>
> Maybe something is wrong on the MGMT network ? but since i can ping IPs
> properly I suspect something more tricky.
>
> If someone could help me giving a look faulty parameters, I can'f figure
> out why my cluster and pod load as null value and make the next
> processes messy
>
> Thanks
>
>
> Xen hypervisor seems good regarding
> storage:10.10.100.11:/exports/primary/ on
> /run/sr-mount/3473326c-6813-97dc-fd85-9f221d59892f type nfs
>
> (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,acdirmin=0,acdirmax=0,soft,proto=tcp,timeo=100,retrans=12,sec=sys,mountaddr=10.10.100.11,mountvers=3,mountport=892,mountproto=tcp,local_lock=none,addr=10.10.100.11)
> 10.10.101.11:/exports/secondary on
> /var/cloud_mount/fb486192-aa16-30d2-9278-c5704f273389 type nfs4
>
>
Re: Questions on snapshots
I'm not sure what is your use case - what you want to achieve - but make sure to test this thoroughly You can "manually" (outside of ACS) always make a snap of the volume, but you need to make sure that this doesn't collide with CloudStack in any way - i.e. there is also VM level snapshots in KVM if you are using NFS as Primary Storage - so check this out maybe it works for you - here for example you have the limitation (if I remember correctly) that you can not attach additional volume (or something similar) to the VM, until you have deleted all VM-level snapshots, etc. (which makes sense of course) I guess it takes a lot of work to skip Secondary Storage (snapshot workflow inside CLoudStack), because you need to make sure to provide workflow for all different Primary Storage providers (there are bunch of them, not only NFS...), and then there are bunch of HyperVisors supported, and so on, so it's a big challenge (I'm not developer, but that is my assumption) Cheers On Sun, 28 Oct 2018 at 00:06, Alexandre Bruyere wrote: > Well... Sounds like the new scripters that are coming in tomorrow will come > in handy. I'll probably have them script something to pull snapshots from > KVM directly instead of going through Cloudstack. > > Is there anything that would stop this from working? > > On Fri, Oct 26, 2018 at 4:15 PM Andrija Panic > wrote: > > > Yes. > > > > There are improvements being done atm, (afaik), to try to manage > snapshots > > on the primary storage (for NFS and maybe CEPH, it's already implemented > on > > i.e. SolidFire). > > > > Simply this is how it was working so far - snapshots are meant to be > moved > > to Secondary Storage (and later can be converted to Templates, downloaded > > from SSVM, converted to volumes etc). > > I agree with you, but that is how it was implemented, I assume for > > compatibility reasons - since different Hypervisors manage things in > > different ways - you have to support different hypervisosrs, different > > storage solutions etc (it's NOT only NFS...). > > > > Cheers > > > > > > On Fri, 26 Oct 2018 at 22:08, Alexandre Bruyere < > > bruyere.alexan...@gmail.com> > > wrote: > > > > > So wait. Are you telling me that Cloudstack does a full backup of the > > > volume every time a snapshot is taken? > > > > > > What's the point of snapshots then? Making specific operations faster? > > > > > > -- > > > Alexandre Bruyère > > > > > > -Original Message- > > > Re: Questions on snapshots > > > From: Andrija Panic > > > To: users > > > Friday, October 26, 2018 at 3:38 PM > > > > > > So :) > > > > > > 1. Snap interval - scheduled snaps are max 1h per the so called > "hourly" > > > schedule - so makes sense :) You could do some automation, by creating > > > manual snapshots and deleting oldest ones via automation - i.e. you can > > > use Cloud Monkey, CLI utility that talk to API and is great for any > kind > > of > > > automation, unless you talk directly to API from i.e. Python etc, via > > > HTTPS. > > > > > > 2. number of snaps: Go to Global Configuration, there is parameter > > > "snapshot.max.hourly" - and you can change it, I assume to <=24 > > ...(restart > > > mgmt server and you are good),(there are similar for daily and monthly) > > > > > > Now, related to snapshots - when you decided to really use them (i.e. > in > > > production) - a BIG warning - make sure to "know" what you are doing... > > > Because so far, when you create a snapshot of the volume on Primary > > Storage > > > (NFS or CEPH), there is really a snapshot that is created almost > > instantly > > > of that volume, but then the whole image (so whole image in that point > in > > > time) is being copied over (qemu-img) to the Secondary Storage NFS - > and > > in > > > case of too frequent snaps, or modest networking, this might at some > > point > > > throttle your network and also break some logic inside CloudStack > > > For example: I had clients that were expecting to do hourly snapshots > of > > > the 2TB image (right... perhaps a too much expectation from their side) > > and > > > this can fail with timeout (in my case it was modest CEPH performance) > > > Also pay attention to schedules, so you don't have hourly snap (one of > > > hourly runs) begin at i.e. 17.00h and then you configured at same time > > > (17.00) daily (/weekly/monthly) at 17.00 (or about the same time) - > those > > > later snaps will simply fail, because there is already ongoing snap on > > the > > > same volume. > > > > > > Sorry long post... > > > > > > > > > Cheers > > > Andrija > > > > > > On Fri, 26 Oct 2018 at 20:53, Alexandre Bruyere < > > > bruyere.alexan...@gmail.com > > > > > > > wrote: > > > > > > > Hello. > > > > > > > > I'm currently investigating the functions of Cloudstack, and looked > > into > > > > snapshots. > > > > > > > > As far as I can tell, the smallest possible interval for snapshots is > > one > > > > hour. Is there a way to schedule them more frequently? For my use, 5 > > > > minutes
