incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Bausewein <>
Subject RE: Review Request: CS-15588 Update systemvm support hypervisor type xen-hvm
Date Wed, 18 Jul 2012 01:07:26 GMT
Hi All,

I've been testing the last couple days with the updated systemvm, and the virtual router,
storage, and console VMs appear to be functioning OK.

I'm still not sure why the xen server is starting the system vm in full virtualization (HVM)
instead of Para Virtualization (PV).  Possibly it's the only available mode when running nested

I'm no expert on virtualization types, does anybody see a problem with the system vms running
in HVM?

Without the change to the cloud-early-config, the system vm fails to read the command line
and assign the correct IP addresses.


-----Original Message-----
From: Sheng Yang [] 
Sent: Monday, July 16, 2012 6:19 PM
Subject: Fwd: Review Request: CS-15588 Update systemvm support hypervisor type xen-hvm

Forward to mailing list.

---------- Forwarded message ----------
From: Jason Bausewein <>
Date: Mon, Jul 16, 2012 at 11:48 AM
Subject: Re: Review Request: CS-15588 Update systemvm support hypervisor type xen-hvm
To: Sheng Yang <>
Cc: Jason Bausewein <>

   This is an automatically generated e-mail. To reply, visit:

On July 16th, 2012, 5:17 p.m., *Sheng Yang* wrote:

I think there is something wrong with virt-what to show xen-hvm instead of xen-domU in nested
virtualization, because I think as long as the systemvm is start by cloudstack, it should
be pv guest(we specify so) rather than HVM guest. It would be possible if virt-what didn't
consider the situation of nested virtualization.

Or it's real xen-hvm guest in this case? Somehow unlikely...

Probably what we need to fix is virt-what, or use some other way to detect the nested virtualization.

 On July 16th, 2012, 6:04 p.m., *Jason Bausewein* wrote:

The script only uses the hypervisor type to load the boot params.  In either case (nested
or not) the boot params should be read from /proc/cmdline.

I don't know much about the different types of xen guests, but the system vm appears to work
fine under a xen-hvm guest.  I have some instances running in a basic zone with security groups,
and traffic is filtered correctly to the instances.

Is there anything I can check from xencenter/xenserver to tell if its really a hvm guest?

 On July 16th, 2012, 6:11 p.m., *Jason Bausewein* wrote:

The console proxies are also working great to the instances and system vms.

 The virt-what script appears to use the cpuid returned by virt-what-cpuid-helper.

I attached output from cpuid running on the system vm if it helps.  It has a hypervisor_id
of "XenVMMXenVMM", same what is returned by virt-what-cpuid-helper.

- Jason

On July 16th, 2012, 6:42 p.m., Jason Bausewein wrote:
  Review request for Sheng Yang.
By Jason Bausewein.

*Updated July 16, 2012, 6:42 p.m.*

When running Xen 6.0.2 under VMware Fusion 4 on Intel Core i7, the command /usr/sbin/virt-what
returns xen-hvm instead of xen-dom0. The system VM cannot read the command line in this case,
and will fail to bind IP addresses assigned via the command line.

In the cloudstack UI, the system VMs will be stuck in the starting state.


Rebuilt system vm with change and it works perfectly.

  *Bugs: * CS-15588

   - patches/systemvm/debian/config/etc/init.d/cloud-early-config (19f87c2)

View Diff <>

View raw message