XEN scheduled snapshots many processes

[Matheus Fontes]

Hi,
We’re using Xenserver 7.0 as Hypervisor and Pre-Setup storage (lvm over 
ScaleIO).
I can see the number of processes increasing day by day in our Xenserver hosts.

I don’t know if it is expected but on each snapshot scheduled xenserver creates 
new processes.
For each lv created kernel show up 2 processes (bioset and kdmflush).

[root@xen4 ~]# ps ax | grep bioset | wc -l
1728
[root@xen4 ~]# ps ax | grep kdmflush | wc -l
1727
[root@xen4 ~]# dmsetup info -c | wc -l
1727

[root@xen4 ~]# dmsetup info -c
Name
  Maj Min  Stat Open Targ Event  UUID
VG_XenStorage--7272653b--0ba2--e4cb--028d--d9899e0dfa55-VHD--7c73f1a3--50b9--4d1d--9f67--53c19abc7c68
 253 1711 L--w01  0 
LVM-Un8sqRvwx9kA8p1WHH8ta5KiBNU4P7X0uv3WZVv8CAZVyAEL3UWGra2n41jimr9k
VG_XenStorage--7272653b--0ba2--e4cb--028d--d9899e0dfa55-VHD--e55873ce--0631--4768--b431--4ba74091293a
 253 1668 L--w01  0 
LVM-Un8sqRvwx9kA8p1WHH8ta5KiBNU4P7X0bPc0Bm4qq3uAQXAQjNC2cGDl00JKY2Pz
VG_XenStorage--7272653b--0ba2--e4cb--028d--d9899e0dfa55-VHD--20b99af9--3584--4a30--a6c5--5c32a53f114d
 253 1674 L--w01  0 
LVM-Un8sqRvwx9kA8p1WHH8ta5KiBNU4P7X0g8ZObr3z5KMEPxji98cxXI3OGw0xEIoL
VG_XenStorage--7272653b--0ba2--e4cb--028d--d9899e0dfa55-VHD--d885da77--58ff--4494--a227--2991e12c6740
 253 1389 L--w01  0 
LVM-Un8sqRvwx9kA8p1WHH8ta5KiBNU4P7X0Jp2PYfUwFHCOqcoRZsaN99tsrAdQdQke
VG_XenStorage--7272653b--0ba2--e4cb--028d--d9899e0dfa55-VHD--e6325c7b--b8b8--4e69--9b6a--f8b998ddd710
 253 1336 L--w01  0 
LVM-Un8sqRvwx9kA8p1WHH8ta5KiBNU4P7X072eGJJoJ89Z2azCl1bWmNI4DDVQkelmq
VG_XenStorage--a622cc0c--d875--bcb0--518c--6d4cc82397c0-VHD--7520f9d5--55fb--4391--bd34--f83bd3f5f90a
 253 1323 L--w01  0 
LVM-HUTMQmzNcjBTkp02u7Yrl586mO3WGTvCLIsQhUJ2a5Pz6FtY3pY10wkiKZUfn2Ek
VG_XenStorage--a622cc0c--d875--bcb0--518c--6d4cc82397c0-VHD--7b884d7d--5132--4fff--8fe9--9980602df6d6
 253 1292 L--w01  0 
LVM-HUTMQmzNcjBTkp02u7Yrl586mO3WGTvCVWByLlQ35Np17i65KrINavgzJcpkWqS2
VG_XenStorage--7272653b--0ba2--e4cb--028d--d9899e0dfa55-VHD--4d693681--dc6b--45aa--861d--3cb897cb395c
 253 1168 L--w01  0 
LVM-Un8sqRvwx9kA8p1WHH8ta5KiBNU4P7X0yfKrMoR8xS4P5wvEX2NIGJcSpJOnUSbt
VG_XenStorage--7272653b--0ba2--e4cb--028d--d9899e0dfa55-VHD--7ed92fb1--d960--4e13--b171--4297c6175468
 253 1219 L--w01  0 
LVM-Un8sqRvwx9kA8p1WHH8ta5KiBNU4P7X0IK3nhs2QwmR9O0gSzkwKdzvMdgIJCPYs
VG_XenStorage--7272653b--0ba2--e4cb--028d--d9899e0dfa55-VHD--a9294ae5--5f56--4e70--b289--d454f59b1473
 253 1135 L--w01  0 
LVM-Un8sqRvwx9kA8p1WHH8ta5KiBNU4P7X0824I07QBaiidCxrsQ0UZ9jXSAdiVSqdc
VG_XenStorage--a622cc0c--d875--bcb0--518c--6d4cc82397c0-VHD--263364aa--ef51--491b--a946--3d19b3b24a50
 253  120 L--r12  0 
LVM-HUTMQmzNcjBTkp02u7Yrl586mO3WGTvC9TzjzywqXJe80ln5sIHYFEHbUmzWsfSn
……….

Re: Get VM OS type

[Riepl, Gregor (SWISS TXT)]

> @Riepl
> nmap -sS -O does help in fetching the OS type only if they have
> public ip. I cant ssh into the machines because they are customer
> machines and I dont have credentials for them.

We had such a situation a few times, and simply asked the affected
customer if they would permit us to deploy a temporary VM into their
network.

You could also use the virtual router as a gateway, but it doesn't have
nmap installed by default.

Re: Get VM OS type

[Rakesh Venkatesh]

Thanks a lot for your replies.

@Riepl
nmap -sS -O does help in fetching the OS type only if they have public ip.
I cant ssh into the machines because they are customer machines and I dont
have credentials for them.


@Nikolaos
ping didnt work for me all the time because few VM's have blocked ping and
in that case, there is no way of telling it. Also, the default TTL values
are outdated in that page. I got a response of 122 for windows vm

On Mon, Jun 17, 2019 at 12:30 PM Nikolaos Dalezios 
wrote:

> Another solution is to ping a VM and check the TTL value.
> Due to slightly different TCP/IP implementation on each OS-family, you can
> identify the OS family by checking this
>  table
>
>
> On Mon, Jun 17, 2019, 12:44 Riepl, Gregor (SWISS TXT) <
> gregor.ri...@swisstxt.ch> wrote:
>
> >
> > > version. Another way is to open the console and see the login screen.
> > > This will get the actual data but I want to do automation to see for
> > > all VM's and opening the console is not feasible to automate. Is
> > > there any other way to get it?
> >
> > Are the VMs networked?
> >
> > You could fetch their public IPs and run nmap -sS -O against them. This
> > should produce fairly accurate results.
> >
> > If they are all on the same Cloudstack network, you could also SSH into
> > a connected VM and run nmap from there.
> >
> > I don't think that there is a generic way to obtain the actual OS
> > running on a VM via Cloudstack. It might be possible through the
> > hypervisor, but nmap will work in most cases.
> >
>


-- 
Thanks and regards
Rakesh venkatesh

Re: Redundant VR Guest IPs

[Rohit Yadav]

Hi Richard,


You've probably found an implementational bug. I think the VIP should be used 
for both source NAT, password, user-data and dhcp/dns services.


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Richard Lawley 
Sent: Monday, June 17, 2019 6:18:46 PM
To: dev@cloudstack.apache.org
Subject: Redundant VR Guest IPs

Hi,

When using RVRs, the guest VMs still see the VR IP instead of the VIP
for a number of things:
* DHCP Server
* Static NAT source IP for hairpin NAT

Just wondering what the reason is for this, as it causes a number of issues:
* Password reset doesn't work if active VR has changed since VM boot
* Issues with DHCP renewals if VR has changed since VM boot (will discuss later)
* Some static NAT connections confusingly (for the end user) come from
the VR IP rather than the VIP

It seems to me that it would be better if anything referencing the VR
IP actually used the VIP, but I'm assuming someone has made a decision
not to do this at some point - just wondered what that reason is, and
whether it's still valid.

Regards,

Richard

rohit.ya...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

Redundant VR Guest IPs

[Richard Lawley]

Hi,

When using RVRs, the guest VMs still see the VR IP instead of the VIP
for a number of things:
* DHCP Server
* Static NAT source IP for hairpin NAT

Just wondering what the reason is for this, as it causes a number of issues:
* Password reset doesn't work if active VR has changed since VM boot
* Issues with DHCP renewals if VR has changed since VM boot (will discuss later)
* Some static NAT connections confusingly (for the end user) come from
the VR IP rather than the VIP

It seems to me that it would be better if anything referencing the VR
IP actually used the VIP, but I'm assuming someone has made a decision
not to do this at some point - just wondered what that reason is, and
whether it's still valid.

Regards,

Richard

[DISCUSS] Move to JDK 11 (LTS) after 4.13

[Rohit Yadav]

All,


JDK 8 (lts) has already reached EOL and we're dependent on distro/maintainers 
and the next available LTS jdk is JDK 11.


Here's the proposal:


- Use JDK8 for building 4.13 and let users decide if they want to run/use JDK8 
(jre) or JDK 11 (jre) for cloudstack management/usage/agent services, the 
systemvm will still have JDK 8 jre


- After 4.13 master is unfrozen, we fix the pom.xml to enforce that JDK 11 is 
used to build master


- New systemvmtemplate is created using the next/upcoming Debian 10 
(https://lists.debian.org/debian-devel-announce/2019/06/msg3.html) release 
and use latest/stable kernel (in Debian 10) and use JDK 11


- Experimental proposal: with 4.14+debian 10 based systemvmtemplate we do not 
bundle JRE within the systemvmtemplate but using jlink 
(https://docs.oracle.com/javase/9/tools/jlink.htm) create a systemvm.iso that 
has a lightweight JRE embeded for use with the ssvm/cpvm agent. The 
systemvmtemplate has about 100-200 MBs consumed due to the JRE installation 
which is only necessary to run cpvm/ssvm agent but adds dead 
weight/storage-size for VRs. If the jlink embedded jre concept works, it will 
also work in our favour and reduce security impact, i.e. in case of a future 
java related security issue we can simply create a new release (with latest 
systemvm.iso and embedded jre) without requiring us to release a new 
systemvmtemplate.


Thoughts, ideas, questions?


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com

rohit.ya...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

Re: Get VM OS type

[Nikolaos Dalezios]

Another solution is to ping a VM and check the TTL value.
Due to slightly different TCP/IP implementation on each OS-family, you can
identify the OS family by checking this
 table


On Mon, Jun 17, 2019, 12:44 Riepl, Gregor (SWISS TXT) <
gregor.ri...@swisstxt.ch> wrote:

>
> > version. Another way is to open the console and see the login screen.
> > This will get the actual data but I want to do automation to see for
> > all VM's and opening the console is not feasible to automate. Is
> > there any other way to get it?
>
> Are the VMs networked?
>
> You could fetch their public IPs and run nmap -sS -O against them. This
> should produce fairly accurate results.
>
> If they are all on the same Cloudstack network, you could also SSH into
> a connected VM and run nmap from there.
>
> I don't think that there is a generic way to obtain the actual OS
> running on a VM via Cloudstack. It might be possible through the
> hypervisor, but nmap will work in most cases.
>

Re: Get VM OS type

[Riepl, Gregor (SWISS TXT)]

> version. Another way is to open the console and see the login screen.
> This will get the actual data but I want to do automation to see for
> all VM's and opening the console is not feasible to automate. Is
> there any other way to get it?

Are the VMs networked?

You could fetch their public IPs and run nmap -sS -O against them. This
should produce fairly accurate results.

If they are all on the same Cloudstack network, you could also SSH into
a connected VM and run nmap from there.

I don't think that there is a generic way to obtain the actual OS
running on a VM via Cloudstack. It might be possible through the
hypervisor, but nmap will work in most cases.

Get VM OS type

[Rakesh Venkatesh]

Hello Folks

Is there a way to know whether the VM is running on Windows or Linux OS? I
can't reply on OS type because we can use Ubuntu as OS type for Windows VM.
Even though the os type is Linux/Ubuntu, the VM is running on Windows
version. Another way is to open the console and see the login screen. This
will get the actual data but I want to do automation to see for all VM's
and opening the console is not feasible to automate. Is there any other way
to get it?

-- 
Thanks and regards
Rakesh Venkatesh