4:56 p.m.
The VMX entry ethernet0.addressType may be set to 'vpx' beside
'static' and 'generated'. 'vpx' indicates that the MAC address
was
generated by a vCenter.
The attached patch adds 'vpx' to the valid values for ethernet0.addressType.
Matthias
4:30 a.m.
From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-
bounces(a)redhat.com] On Behalf Of Matthias Bolte
The VMX entry ethernet0.addressType may be set to 'vpx' beside
'static' and 'generated'. 'vpx' indicates that the MAC address
was
generated by a vCenter.
The attached patch adds 'vpx' to the valid values for
ethernet0.addressType.
Matthias
[IH] can you please explain the interaction (if any) between the ESX
driver and
vCenter which this patch implies may be working with same ESX servers?
Thanks,
Itamar
5:12 a.m.
2009/8/10 Itamar Heim <iheim(a)redhat.com>:
> From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-
> bounces(a)redhat.com] On Behalf Of Matthias Bolte
>
> The VMX entry ethernet0.addressType may be set to 'vpx' beside
> 'static' and 'generated'. 'vpx' indicates that the MAC
address was
> generated by a vCenter.
>
> The attached patch adds 'vpx' to the valid values for
> ethernet0.addressType.
>
> Matthias
[IH] can you please explain the interaction (if any) between the ESX driver
and
vCenter which this patch implies may be working with same ESX servers?
Thanks,
Itamar
The ESX driver parses the VMX file of a virtual machine to gather the
information needed for the dump XML function. The VMX entry
ethernet0.addressType maybe set to vpx if the generated MAC address
was generated by a vCenter and not by the ESX host itself. No direct
interaction between the ESX driver and a vCenter happens in this case.
But there is direct interaction between the ESX driver and a vCenter
if you order the ESX driver to migrate a virtual machine from ESX host
A to ESX host B.
An ESX host itself is not capable of initiating a migration to another
ESX host. Both hosts must be attached to the same vCenter and the
vCenter initiates and controls the migration. So the ESX driver needs
to know the vCenter for a ESX host in order to do a migration.
Therefore the ESX driver URI format contains an vcenter query
parameter.
More detailed documentation in HTML form will be added soon.
Matthias
5:18 a.m.
From: Matthias Bolte [mailto:matthias.bolte@googlemail.com]
...
The ESX driver parses the VMX file of a virtual machine to gather the
information needed for the dump XML function. The VMX entry
ethernet0.addressType maybe set to vpx if the generated MAC address
was generated by a vCenter and not by the ESX host itself. No direct
interaction between the ESX driver and a vCenter happens in this case.
But there is direct interaction between the ESX driver and a vCenter
if you order the ESX driver to migrate a virtual machine from ESX host
A to ESX host B.
An ESX host itself is not capable of initiating a migration to another
ESX host. Both hosts must be attached to the same vCenter and the
vCenter initiates and controls the migration. So the ESX driver needs
to know the vCenter for a ESX host in order to do a migration.
Therefore the ESX driver URI format contains an vcenter query
parameter.
More detailed documentation in HTML form will be added soon.
Matthias
[IH] thanks for the elaboration. So the driver can talk to both an ESX
server directly, or to vCenter. vCenter is used only for specific
operations (like live migrations), and you opted to connect directly to
ESX (rather than use vCenter API to start a VM as well) for the rest to
allow using in a vCenter-free environment as well?
Are there any other considerations to using ESX directly, or prefer to use
vCenter (say, if you ask vCenter to start the VM, you could benefit from
its load balancing capabilities, etc.).
Btw, does asking ESX to start a VM from shared storage checks for locks,
and prevents running same VM on two ESX in parallel, or must vCenter be
used for "cluster-aware" use cases?
Thanks,
Itamar
6:18 a.m.
2009/8/10 Itamar Heim <iheim(a)redhat.com>:
> From: Matthias Bolte [mailto:matthias.bolte@googlemail.com]
...
>
> The ESX driver parses the VMX file of a virtual machine to gather the
> information needed for the dump XML function. The VMX entry
> ethernet0.addressType maybe set to vpx if the generated MAC address
> was generated by a vCenter and not by the ESX host itself. No direct
> interaction between the ESX driver and a vCenter happens in this case.
>
> But there is direct interaction between the ESX driver and a vCenter
> if you order the ESX driver to migrate a virtual machine from ESX host
> A to ESX host B.
>
> An ESX host itself is not capable of initiating a migration to another
> ESX host. Both hosts must be attached to the same vCenter and the
> vCenter initiates and controls the migration. So the ESX driver needs
> to know the vCenter for a ESX host in order to do a migration.
> Therefore the ESX driver URI format contains an vcenter query
> parameter.
>
> More detailed documentation in HTML form will be added soon.
>
> Matthias
[IH] thanks for the elaboration. So the driver can talk to both an ESX
server directly, or to vCenter. vCenter is used only for specific
operations (like live migrations), and you opted to connect directly to
ESX (rather than use vCenter API to start a VM as well) for the rest to
allow using in a vCenter-free environment as well?
Yes, currently the driver prefers the ESX host and only uses the
vCenter for task an ESX host cannot perform on its own. This way the
vCenter can be optional and the driver also works with a vCenter-free
setups.
Are there any other considerations to using ESX directly, or prefer
to use
vCenter (say, if you ask vCenter to start the VM, you could benefit from
its load balancing capabilities, etc.).
Currently there are no such considerations. but I'll put this onto the
todo list to think about it.
The basic problem with the vCenter and libvirt is that the vCenter
doesn't fit into libvirt's world model. libvirt only knows about
hosts/nodes and virtual machines/domain running on them. Higher
management instances like the vCenter are outside libvirt's world
model.
Btw, does asking ESX to start a VM from shared storage checks for
locks,
and prevents running same VM on two ESX in parallel, or must vCenter be
used for "cluster-aware" use cases?
To be honest I'm not sure and I haven't tested it yet, but I assume a
vCenter I not necessary in this cases.
Running the same VM on two ESX hosts in parallel should be prevented
by lock files that are created by the ESX host itself.
The cluster-awareness for basic file access should be in the file system itself.
Matthias
5:08 a.m.
On Sat, Aug 08, 2009 at 11:56:10PM +0200, Matthias Bolte wrote:
The VMX entry ethernet0.addressType may be set to 'vpx'
beside
'static' and 'generated'. 'vpx' indicates that the MAC address
was
generated by a vCenter.
The attached patch adds 'vpx' to the valid values for ethernet0.addressType.
Matthias
diff --git a/src/esx/esx_vmx.c b/src/esx/esx_vmx.c
index 54c2594..70e9305 100644
--- a/src/esx/esx_vmx.c
+++ b/src/esx/esx_vmx.c
@@ -276,6 +276,10 @@ def->nets[0]...
ethernet0.addressType = "static"
# default to "generated"
->mac = <value> <=> ethernet0.address =
"<value>"
+
+ ethernet0.addressType = "vpx"
# default to "generated"
+->mac = <value> <=> ethernet0.generatedAddress =
"<value>"
+
#
00:0c:29 prefix for autogenerated mac's
#
00:50:56 prefix for manual configured mac's
#
00:05:69 old prefix from esx 1.5
@@ -1369,7 +1373,8 @@ esxVMX_ParseEthernet(virConnectPtr conn, virConfPtr conf, int
controller,
goto failure;
}
- if (addressType == NULL || STRCASEEQ(addressType, "generated")) {
+ if (addressType == NULL || STRCASEEQ(addressType, "generated") ||
+ STRCASEEQ(addressType, "vpx")) {
if (generatedAddress != NULL) {
if (virParseMacAddr(generatedAddress, (*def)->mac) < 0) {
ESX_ERROR(conn, VIR_ERR_INTERNAL_ERROR,
@@ -1390,8 +1395,8 @@ esxVMX_ParseEthernet(virConnectPtr conn, virConfPtr conf, int
controller,
}
} else {
ESX_ERROR(conn, VIR_ERR_INTERNAL_ERROR,
- "Expecting VMX entry '%s' to be 'generated' or
'static' but "
- "found '%s'", addressType_name, addressType);
+ "Expecting VMX entry '%s' to be 'generated' or
'static' or "
+ "'vpx' but found '%s'", addressType_name,
addressType);
goto failure;
}
ACK
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
9:28 a.m.
On Sat, Aug 08, 2009 at 11:56:10PM +0200, Matthias Bolte wrote:
The VMX entry ethernet0.addressType may be set to 'vpx'
beside
'static' and 'generated'. 'vpx' indicates that the MAC address
was
generated by a vCenter.
The attached patch adds 'vpx' to the valid values for ethernet0.addressType.
Okay, I finally commited this patch :-)
thanks !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
5590
days inactive
5615
days old
6 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Itamar Heim -
Matthias Bolte